CI/CD series - Altran: What's driving the continuum?

This is a guest post for the Computer Weekly Developer Network in our Continuous Integration (CI) & Continuous Delivery (CD) series.

This post is written by Jitendra Thethi, AVP of Technology and Innovation at Altran — the company is known for its software product development and consultancy services.

Thethi writes as follows…

Continuous Integration and Continuous Delivery helps to accelerate product development in an Agile manner and deliver features faster than waiting for long release cycles. There are many open source and commercial tools that support CI/CD — and most fall into the following categories: source code management, build management, static code analysis tools, continuous testing and validation, continuous deployment, penetration testing, regression testing tools, infrastructure monitoring tools and application monitoring tools

So, how do you get started? First things first.

CI/CD goes hand-in-hand with DevOps and the move to DevOps is a culture change for many teams. They need to assess requirements and take incremental steps, rather than a big bang approach. Development and operations teams need to start working together on automating the build and deployment to remove the dependency on any manual tasks.

Measuring effectiveness

Of course DevOps has many pitfalls. Rather than focusing on the tools, examine the processes. There should be a clear measurement of the efficiency improved from the adoption of these practices and tools. Skills and the experience of adoption is a key ingredient in the transformation journey to DevOps.

CI/CD is not another Agile iteration, instead it has to be considered as part of the development cycle. Anything that is developed has to be automatically built, tested and deployed. Measuring the effectiveness of a CI/CD system is critical. The effectiveness is measured as ‘agility matrices’ that are derived from events that come from different DevOps tools and reflect KPIs such as build velocity, build quality and cycle time, developer productivity and release cycle times etc. Ideally the goal is to deploy any pull requests and have the ability to merge it to the master branch directly within a staging environment. The deployment into the production environment may depend on other business factors.

CI/CD is more disruptive for legacy systems.

It can therefore take more effort and be time intensive for teams to adopt new practices. For some teams, build cycles can get longer because of the additional computation required in the CI/CD pipeline.

Second nature CI/CD

However for new systems, as long as the DevOps discipline is instilled at the onset – it is not at all disruptive. Over time it becomes second nature and then it becomes part and parcel of the development cycles.

… and finally, security is critical. It should never be an after-thought or a bolt-on capability. It has to be followed throughout the architecture to deployment cycle.

Integrate security as part of the build and deployment cycles.

That way, products get developed as ‘secure-by-default’ and security does not become a barrier to agile deployments. Build a foundation of DevOps and CI/CD knowledge and this will lead to deeper security insights across development, operations, infrastructure and applications.

Thethi: Continuous about continuum.