×
![Modal Image]()
Every software development team has its own deployment process according to its needs, and for a long time, our team at Amplified did deployments at the end of a sprint. However, we recently made the switch to a continuous integration/continuous delivery/deployment (CI/CD) process - here’s why.
It’s important to note here that while we recognized that CI/CD makes the most sense for certain projects, we haven’t switched over exclusively to CI/CD for all our projects. Some of our teams on different projects continue to use regular sprints and deploy at the end of a sprint. At the end of the day, the right approach is what makes sense for the project and for the client, and it’s essential to remain adaptable to that.
That said, what made us aware that we needed to switch to a CI/CD approach for this project?
The first sign that we needed a new approach was the fact that we were working with engineers across several time zones, and synchronizing all the engineers for deployments was close to impossible.
We also wanted to keep the application smooth and reach a low bug count. Daily, each of our engineers tries to dedicate 40% of their day to bug fixing/testing/refactoring and 60% to actual coding. We would fix important bugs every day, and having them reach production as soon as possible was imperative for us; waiting until Friday didn’t align with this need.
Quality customer service was also weighing on our process. Being a start-up studio, we mainly work with start-ups, and we all know how important it is for a start-up company to make itself noticed in the market. We also knew how important it was to deliver valuable, quality service, especially in the beginning.
When attracting users to the app, you need to keep pace and deliver on time. It could be a feature that would take one day of implementation, but responding promptly to the customer’s requirements brought value to the project, and we needed to speed up that process.
Staging is the testing environment where we deploy features to be tested; once they are working smoothly, they’re deployed to production. However, we found that often one engineer would have a feature stable on staging and would like to deploy to live. Meanwhile, other engineers’ features were not stable enough to reach live, so they would need to start rolling back.
This created a lot of issues: the engineers would start working directly on the branch that was directing all the code to staging, with no possibility of roll-back. This then forced them to cherry-pick the features that weren’t going to live yet and move them to a separate branch.
Before implementing our CI/CD process, we used to have deployments only once a week or once every 2 weeks (depending on the sprint length). 80% of the time, those deployments would happen on Fridays, at the end of a sprint, to “crown” the sprint with the final results the engineers have been working on during the sprint time. Deployments in mid-sprint were uncommon, only occurring if there was an emergency.
We started to notice the pressure Friday deployments were bringing to our team, including server crashes and bugs that cropped up right before the end of the day. Ultimately, we realized right before the weekend was not an ideal time to do deployments. We decided to start doing deployments on Thursday.
After switching to Thursday, we noticed we had more time to catch bugs before they reached live, which was an improvement. However, in these cases, the additional time we needed to fix them would spill over into Friday, and we’d still end up having deployments on Fridays.
Also, we thought we’d be fixing small issues, but we found ourselves in situations where a small fix would snowball into multiple issues on production if even the smallest detail was missed. This brought us to the initial problem: the team being pressured to deploy a properly functioning version on Friday evening.
Recognizing these issues and needs, and realizing that our Thursday switch still hadn’t resolved them adequately, we decided to implement a CI/CD process instead. The benefits of CI/CD addressed many of the issues we were having in our current process.
Smaller Code Changes
CI/CD allows you to integrate small pieces of code at one time and test it right away. This meant we could catch problems faster and fix them easily by identifying exactly where the problem lay. This also helped with team communication across time zones and distance, because we could identify the problem before more work was done.
Faster Release
By continuously integrating, testing, and deploying code, we were able to release fixes much faster than before, instead of waiting until the end of the week to release the changes in bulk.
Happier Customers
Fast releases of new features and bug fixes had a positive effect on our customer service. Users were getting a better version of the product and getting fixes quickly, which gave them a good impression of the product and the company.
Less Backlog
With fixes and deployments happening on a rolling basis, we saw less backlog and confusion in staging. There were also fewer issues that we hadn’t prioritized waiting to be addressed on the back burner.
