Continuous Delivery (CD) is a software development methodology in which iterations are delivered frequently, without following a fixed release schedule. While the final production deployment step is done manually, the idea is that whenever the code merged is potentially production-ready, a new release can be deployed.
The plan is to switch all Planet 4 deployments to Continuous Delivery around end of April – beginning of May and improve the process as we move forward with it.
Switching to Continuous Delivery will help us fix, test, respond, deliver and iterate faster. It will improve both development and the UAT (User Acceptance Testing) process. As we grow confidence in our testing and deployment process, our code quality will also be improved. With this change we would also get a bit closer to the well-known Open Source principle: “Release early, release often“.
What CD will bring to Planet 4
- Responsiveness – With the current release schedule, blocker issues have to wait a week to get to production sites. The team wants to better support the P4 community and respond quicker to stakeholders’ emergencies, and releasing increments as soon as they are ready is a good step in that direction.
- Code Quality – The team’s efforts to expand and improve automated tests and review processes gradually brought P4 to a point where the merged code is considered production-ready and deployable at any time. Continuous Delivery of increments brings in more tests and more reviews, pushing the team to write better code. Better code means better product.
- Reliability – With more frequent releases, the number of actual code changes decreases, making the discovery (and fix) of any problems easier and quicker. As before, the pipeline can automatically roll to a previous version if anything happens to fail.
- Faster contribution process – If supported by parallel services (onboarding process, communication channels etc) Continuous Delivery enables quick integration of anyone willing to contribute at any point in time, for all magnitudes of work.
Potential Challenges of a CD adoption
While Continuous Delivery is expected to bring in all the above-mentioned PROs, it might bring some challenges as well:
- Confuse the community – A key part of shipping the increment into the product is make sure the impacted parties are aware of the change, and warned if such change has a critical impact. It’s easy to miss something, when upgrades are frequent, so we need to make sure the P4 community is involved and informed, but not spammed. The right mix of automated comms, notifications in chats, community calls and documentation has to be found.
- Technical documentation not up to date – We plan to include the people who write the technical documentation earlier in the process. There will be a series of changes that will affect the work of our editors, so those pieces specifically need to be thoroughly documented in the Handbook beforehand.
Communication cycle
To make sure the P4 community is up to date and properly informed about relevant changes, the idea is to keep everyone informed with a mix of automated and manually crafted messages, supported by constantly updated documentation.
Measure performance before and after CD
From the development point of view:
- Compare Sprint and Velocity reports before and after the process
- Developers assessment after a period of 3 months
From the community point of view:
- Community assessment via a Google form after a specific timeframe (6 months, 12 months) to see if comms on product are perceived more efficient / invasive / too high level or similar
Development Cycle
In the Continuous Delivery scenario, each time a new Pull Request is created, automated tests and peer code review are immediately taking place. By using a test instance to deploy the change, the engineer in charge can ask other team members to verify it during User Acceptance Testing (UAT).
The P4 Git branching strategy will also change with Continuous Delivery. The current Git-Flow, with two main branches (master, develop) and one for the next release, will be replaced by Github-flow, where there is only one main branch (master), constantly updated with great quality code, ready to be deployed in production sites.
For UAT to take place before “Merge”, a branch needs to be deployed on a test instance. We created a swarm of test instances that can be used by the engineering team to deploy the changes and a dashboard to show their availability in color coded way.
Finally, a new data sync automation was implemented in our CI, allowing us to sync these test instances with content from any production instance.
*This post has been written in collaboration with Luca Tiralongo and Nikos Roussos
