3 Learnings to Help Transform Your CI/CD Pipeline

Hi! My name is John Hansen and I’m a Principal DevOps Engineer here at Artera. I was (and am) part of a team responsible for helping change the velocity of Artera’s release cycle. As an organization, we are always looking for ways to be more effective and successful in our operating model, and our release pipeline is certainly an important part of it. In this blog, I want to share 3 learnings that may also help you transform your CI/CD pipeline.

A brief history of our release pipeline to today

When a few teammates and I began our journey two years ago, Artera was still a young company. Our releases to Production took place once every two months – essentially, our engineers spent two months building many features and we would release them all at once. Each release was a carefully planned two-week effort by multiple teams so that all of these features would be safely delivered to our customers. The night of the release, our Engineering, DevOps, QA and Product teams had one or two representatives ready to smoke test their part of the application after the new version was deployed to each of 6 environments.

Fast-forward to today

As Artera grew, so did our internal operations. We now release code to every one of our Production environments once every two hours on an automated schedule. Instead of waiting two months to deliver a large size of code, we now deploy small incremental changes. This benefits both our customers and our internal teams.

• From the perspective of our customers, they are able to see product enhancements or new features more frequently. It is very possible that every two hours when we release to production, we are adding some level of value change. The speed to market undoubtedly improves our ability to deliver even more value to our customers.
• From the perspective of our internal team members, it is so rewarding to see our ideas go live right away. It is much safer to release smaller increments of code since they promote modularity and enhance code organization, making them easier to manage. In the rare event that we introduce a bug in production, the current release pipeline also makes it easier to diagnose and resolve the issue at a timely basis.

3 critical learnings that may transform your CI/CD pipeline strategy

The project to improve our release pipeline took a little over a year and a half to complete. I am here to share several learnings that helped us successfully transform our strategy for releasing code frequently and reliably:

1. COMMUNICATION My teammates and I were aware that we were changing the way that the Engineering teams worked. We kept closely in touch with them and provided regular updates. Our fearless VP of DevOps also met regularly with the senior leadership team to keep them informed of our progress. Whenever a decision needed to be made or an impediment needed to be addressed, there is always support to help the teams move forward. It was critical that we communicated any changes needed. This included a shifting of mindsets about branch methodologies, pre-production deployment practices, QA work, and even low-level details such as how SSL certificates and application configuration are handled in code. Having this transparent communication made sure everyone was aligned to the change and we were able to “turn on” the new pipeline efficiently and effectively.
   
2. CRITICAL THINKING As a DevOps professional, it’s fun to learn technologies and dream about the best practices to use them. However, tools in technology are designed to be flexible. Code and infrastructure becomes unique and bespoke to each company, each product, each team, each engineer. It’s a given, it’s natural. We were able to suggest a few changes from Engineering teams as we discovered incompatibilities with our pipeline redesign. But for the most part, it was up to us in DevOps to learn and adapt our knowledge of those tools to the entire application stack as we deconstructed it. This was an environment where we could think creatively, but also critically, as this change impacts not just our internal people and processes, but ultimately our customers.
   
3. PATIENCE Along with critical thinking came patience. It took time to learn how our application actually works under the hood. Months of time, months of patience, months of understanding from everyone involved. Unwinding years of iterative design and technical debt was a process that couldn’t and shouldn’t have been rushed by anyone, from the boots-on-the-ground DevOps team over to the Engineering teams and up to the leadership of the entire company. This reformation project was a complete success because each person on our team and here at Artera were patient and excited for what we were building. While we had a timeline to follow, we only felt the pressure of making the right decisions along the way. The Navy SEAL motto is often used here at Artera to keep us from rushing into mistakes, “Slow is smooth and smooth is fast.” This line certainly serves as a compass for us to always be patient.

These lessons will stay with me for all of my future projects. I’m thankful for the chance to share them with you too. Happy pipelining!

Legal Disclaimer: The contents of this post as well as the opinions expressed herein do not contain business advice. The business information provided is for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any actions based upon such information, we encourage you to consult with the appropriate professionals. THE USE OR RELIANCE OF ANY INFORMATION CONTAINED IN THIS POST IS SOLELY AT YOUR OWN RISK.