Many engineers wish for a company culture where empowerment, decision making, collaboration and innovation all play an important role in their daily lives. Having such a culture provides great opportunities, but it also poses many challenges. To feel comfortable in such an environment, the two key ingredients are supporting leadership, and adequate tooling. I’m happy to say FAIRTIQ has both - this article is about Continuous Delivery, a centrepiece of the tooling.
Continuous Delivery is a software development approach of working in short cycles, to deliver applications to end users often. These short cycles are only viable if the release process is simple and error-proof. It requires switching the delivery process from time-consuming and manual, to error-proof and automated. That way, you can release as often as you want, even multiple times a day.
Having the ability to release a backend service often, even daily, is evidently useful. However, FAIRTIQ’s main product is a mobile application, and the industry standard for mobile app update frequency is one to four updates a month, not 30! So, what’s the point of having CI/CD on mobile, I hear you ask. Admittedly, we didn’t start because we wanted to release daily, but because we wanted to release reliably. But CI/CD on mobile eventually provided much more.
FAIRTIQ was launched in 2016, after only 4 months of development. After the initial release, the company and the product grew really fast. All the rush and competition was hurting our code quality, automation and testing. Releasing the app was a time consuming manual process and we used to make lots of mistakes
This is when our CTO, Michel Yerly, decided to bring Continuous Delivery to mobile apps. We were in 2018 and he had quite a bold and ambitious vision back then: to be able to release our mobile applications with a single click of a button. This was a rather innovative idea at the time: whereas many companies were using CI/CD for backend, rather few people were talking about CI/CD for mobile. We couldn’t find documentation, discussions, blog posts, best practices and alike.
With support from the company leadership and mentoring from Michel, we started by learning about the topic. It quickly appeared to us that not only was the final destination worth it, but also every step we took towards Continuous Delivery would already imply an improvement in quality.
We started our journey towards CI/CD on mobile by adding automated tests, something we lacked at the time. We needed more confidence in our code base to release any commit to production. Coming up with an effective testing strategy and operating it is just as important as automation.
We also needed to improve how we develop: going from long cycles to short ones. Transforming a team’s mindset requires great effort. When we started, most of the team thought the goal of releasing whenever we wanted was too ambitious. We needed many iterations of ‘explain - motivate - try - assess - repeat’. After a few cycles, people started to see the benefits.
We had to re-align the goals, and care for people’s motivation, many times. Personal development played a crucial role, since nobody was an expert in CI/CD solutions for mobile. Establishing a shared vision allowed to bring people onboard and make them feel part of the process. It also helped in moments of doubt, to go back to something we all decided to achieve together. Today the team has the Continuous Delivery mindset, not only when it comes to development, but for planning as well.
Today, we’re at a point where we can release whenever we want. At FAIRTIQ, we treat improvement work as an essential part of our day, not just as a task that is once done and finished. We’ve come a long way, but there’s always something to improve or something new to automate - so, our Continuous Delivery efforts are still ongoing.
We didn’t expect to make everything right on the first attempt, but we were determined to learn from all the mistakes we’d make along the way. I’d like to highlight three of them.
Firstly, we did not apply clean code principles to infrastructure code from the start. A broken release pipeline needs to be fixed right away, but it’s easier to do when best practices are used in infrastructure code as well. We didn’t prepare for that, and we wrote spaghetti CI config. We learned we needed to consider infrastructure code just as important as the rest, simply because similar to the code of our product, infrastructure code also lives long, evolves, and it requires maintenance.
Secondly, some of our releases went wrong, while others had bugs and needed a hotfix. This is natural - your CI/CD pipeline won’t be perfect from the start and you’ll have the chance to improve it. Our erroneous releases weren’t caused by CI/CD itself, but rather the lack of good test coverage. CI/CD only highlighted the problem, and we were happy to improve.
And lastly, we didn’t anticipate moments of doubt - but these happen when your team ventures into uncharted territory. Going back to something we all decided to achieve together was a motivation boost for the team. We learned that having a manifesto of some sorts is really helpful.
With the continuous delivery mindset came continuous improvement. Today, if something fails, we always ask: could we have caught the same issue earlier in the process? If we discover an issue, could we have caught it with a unit test? If not, maybe a UI test? Most of the time, the answer to one of these questions is yes, and it improves quality greatly.
We now have greater confidence in the quality of our apps than ever before. We take pride in our state-of-the-art delivery process, and high quality standards.
Since many people were involved, CI/CD helped have better collaboration among people who otherwise rarely work together.
By reducing lead time, from feature design to production, we reap many benefits every day:
It’s 2023, and the majority of companies have Continuous Delivery in place. But for many, it’s only a technical feat. At FAIRTIQ, CI/CD also shaped how we approach the software development process. Engineers are in charge end-to-end, meaning that as developers, we are responsible for the code we put in production. We don’t rely on any other team or QA engineers to test our code. We have the empowerment to make decisions, and we’re ready to do so responsibly.
Continuous Delivery is an essential tool to have this kind of empowerment, decision making, collaboration and innovation as an integral part of our daily lives.