Don’t get into CI before considering these 7 Steps…

Continuous Integration is a software engineering practice aimed at improving the overall quality of products by providing early feedback at every step of the PDLC. It’s anchored by 4 main concepts: standardized code integration, automated build system, repeatable deployment to staging environment, and efficient testing discipline (unit, functional, regression).

However, this is not about the mechanics of implementing CI, there are many sources of detailed information on how to do that…Martin Fowler’s blog is an excellent source, in addition to open source projects such as Jenkins and services like Travis CI and Bamboo.

Sharing the 7 steps to ensure your CI journey delivers on the desired outcomes; they’re based on our own large scale CI transformation journey...We're still learning!

 1. Examine forensics of your technology stack

CI is not a one size fits all implementation…every technology stack has it’s nuances that have to be taken into consideration when designing the right solution. Homogeneous environments allows for better standardization of workflow design. On the other hand, heterogeneous/polyglot environments present different challenges. We designed our solution for a technology stack that includes components in C++, several flavors of Java frameworks, Python, and node.js. Another consideration is the characteristics of monolithic vs componentized application stacks…dependency management and isolation assessment is critical in ensuring visibility into unintended consequences.

 2. Assess organizational readiness

Generally, teams operate at different coding/testing velocities. It’s important to take that into consideration when designing workflows that integrate different components into a CI system. Customers care about the value delivered by solutions. Get a feel for existing engineering practices; engineers are the best source of feedback on pain points, weaknesses in the pipeline, and overall problems to be solved. Teams may be unable to automate their tests because of bad software design, lack of expertise, or unreliable dependencies.  Don’t implement solutions that can’t be adopted.  

3. Get executive buy-in

Getting to efficient CI practice is a journey, and it’s generally a long one. It’s imperative to get executive sponsorship…there will be situations where market demands dictate the pace and practices adopted for developing products…Shortcuts might deliver short term results, but we know that all you're doing is adding to the technical debt that has to be cleaned up at orders of magnitude the cost of sticking to the right practice. This is a call easier made if you have the executive leadership on your side.

4. Prepare the foundation

Getting the organization on the right CI track won't be easy. Telling the story at engineering roadshows and tech-talks on the benefits of CI is crucial to get the engineers excited about the program. In addition, communicating a few immediate activities that engineers can do to start realizing the benefits helps make the CI journey real. Activities such as standardizing the code repository hygiene, standardizing the branching strategy, getting engineer used to testing often, and standardizing code delivery around pull requests (code review is implied).

5. Influence the behavior

Target a few key engineers who are viewed as thought leaders, and who have the credibility in the organization as code ninjas…This group is the core, they would anchor your implementation and rollout strategy. Moreover, they’ll have a huge influence on building the culture of quality that’s very fundamental to a successful CI program. Engage these engineers through partnerships and white glove support to get them up and running, and productive!

6. Establish the governance model

CI governance is not about calling out non-compliant engineers…the carrot approach is much more effective. However, CI is about early feedback, so invest in building the tools, portals, and effective integration to provide the engineers self-governance. Engineers want to do the right thing, so enable them to do so with minimal friction, and clear accountability. Design systemic checkpoints to identify quality issues…it’s hard to argue with that approach. Help your engineers be successful.

 7. Iterate based on engineering experience

CI is a practice by engineers, for engineers. Realize that you won’t get it right the first time, and be ready to iterate as the PDLC ecosystem evolves. Implementing a feedback system will ensure surfacing issues related to scale of the code base, dependency complexities, and engineers operating in different geographies across several time zones with varying levels of skill and training.

Overselling CI without thinking about these 7 steps would jeopardize the desired outcomes…in addition, lacking credibility in implementing the right solution would make your job doubly challenging when you talk about complementing the CI practice with Continuous Delivery (CD)…The journey continues!