JDi Solutions is a small, distributed team of developers who are passionate about improving public service delivery through technology.
Over 30 local government clients in the UK use JDI's online consultation software and websites. District, borough, city, and county councils are examples.
Upgrading the site to Symfony 4
Previously, JDI Solutions were using a version of Opuscon that was built on the Symfony 3 framework.
They didn’t want to have to come to us every time they build a new site.
However, as there are many sites that are very similar, it made sense to automate their creation. In this case, the decision was made to use Jenkins. So, if JDi wants a new Opus Con site, they can fill in a form in Jenkins, and it’ll build one. In this way, it’s acting almost like a site builder.
In 2021, JDI decided it was time to upgrade to Symfony 4. This is where we stepped in.
Firstly, we created a proof of concept. Then we had to undergo a lot of Ansible work to make it work with Symfony 4. Though this work was mostly in the background, investigating internal elements to ensure a smooth upgrade process.
Following the preparation, we then began to migrate their existing sites onto the newer Symfony 4 version.
What we did
There were roughly 30 sites that needed moving across. So making things a little easier reduces the time taken to get them all done. Firstly, we got a Jenkins job set up, using an existing job as an example, which was used to create a Jenkins job for each site.
Doing it this way saved time and removed a lot of the human interaction.
The plan was for these deployments to create a new, static database during the initial build, and from there it used that static database rather than a rolling database. This is because this Symfony setup didn’t have a maintenance mode and, with deployments potentially happening in the day, we did not want to risk some data being manipulated in the old database while a deployment was running, using a new one if rolling databases were used.
Ansible role
Also, after further talks with JDi, we needed to adjust one of the Ansible roles in the repo so the files directories match the existing structure. Because, in some cases, there are a lot of files, copying them to the new S4 site would’ve been time-consuming, especially given they were on an EFS volume.
In that role, we were using the built-in file module to ensure the directories exist. Looking at the documentation, using state: directory meant the path would be created if it did not exist, but wouldn’t affect anything that did already exist.
Conclusion
In the end, our role was to deliver the custom Ansible code for deploying Symfony 4 multi-sites, making template Jenkins job, making template virtual hosts, preparing the custom deploy code for each individual client site then proofreading and double and triple-checking JDI's own script and steps for a smooth migration.
We have now successfully:
- Migrated all sites
- Deleted all the old code folders from the server
- Merged the code into master, demo and prod
- Switched all the builds to use the prod branch except demo which uses the demo branch
- Got the get the demo site to auto-build when we push a change to the demo branch
- Upgraded their site to Drupal 9
