Demystifying Continuous Integration and Delivery

It’s often commonplace in a transformation talk to make fun of waterfall as a delivery methodology. But that’s often not fair. Waterfall works great if your requirements are unchanged. Your user is well understood and you don’t need to be highly adaptable to user’s changing needs.

Unfortunately we don’t live in a world where we can embrace what Kent Beck called ‘Big Design Up Front’. The notion that we sit down, plan an entire release and execute that software development life cycle in a batch and queue style.

The past is littered with failures that all predicated their implementation on ’Big Design Up Front’. Does the very mention of the word Titanic give you that sinking feeling? Big Design Up Front, what could possibly go wrong?

There’s a myriad of these examples in our past. If we can train our eyes to see them then we can train our minds to learn from them. This may be just what your project needs to prevent taking on water and sail your way to success.

Learning from these examples is imperative to our very existence. We are surrounded by constant change and overwhelmed with new technology every day.

This means we need to embrace a new delivery methodology that enables us to be highly adaptable to market need, changing requirements and new technology. In such a fast changing environment, CI (Continuous Integration) and CD (Continuous Delivery) are now a necessity and not a luxury.

Continuous Integration Principles

Continuous integration is a software development practice where development teams integrate their code often into a shared repository. By integrating code often developers can ensure that their code is not harmful to other parts of the system.

Each integration is verified by an automated test and build and very often a series of test suites are invoked to ensure breaking changes are not introduced into the main code line.

Another benefit of a continuous integration system is the notion of immediate feedback. By integrating changes often developers receive immediate feedback on the quality of the code they’re delivering. Reducing cost of fixing issues. Bugs are often found and fixed within minutes or hours instead of days or weeks. Below are some key tenants of continuous integration:

• Automate, automate, automate.
• All new code and builds are automated leaving the work machines are good at, to machines
• All changes are merged into a single repository
• All builds are performed on a dedicated machine.
• Breaking changes fail tests and the build system disallows those changes to be checked into the mainline
• Visibility is key, everyone should be able to see what’s happening
• Automate deployment

Continuous Delivery

A key objective of any organization is to deliver software that meets customer needs and in turn drives revenue. To achieve this, they need to be able to deliver their software in the shortest time possible, and measure its value.

CD is about releasing software frequently, and reliably, in a frictionless manner. It’s important to note that delivery means placing the build in the hands of the customer, not in the hands of IT. For this reason we need to make sure our code is always production- ready, without the requisite automated testing this is hard or impossible to do quickly.

Comprehensive automation and validation at every step of the product development lifecycle is an integral part of CI/CD. This also implies that developers aren’t done with a feature when it is delivered to QA, or some internal IT system. They are done with the feature when it is deployed to production.

Continuous Delivery Steps

Often the simplest way to understand a concept is to examine a real world example. To understand continuous integration and delivery in a real world way, we need to follow a developer’s activity.

1. Download the latest, integrated software from the central repository
2. Developer implements a specific feature or capability
3. Implement necessary tests in an attempt to prevent the new code from introducing breaking changes
4. Carry out an automated build which will take the existing code base and a developer’s changes and verify they compile and pass tests
5. Once the code passes tests and builds on a developer’s machine this code can then be integrated into the central code repository

Key take away, by integrating regularly, you can detect errors quickly, and locate them more easily.

Additional Benefits

Continuous Integration brings a whole host of other benefits to your organization:

1. Unvalidated risk and effort does not accumulate. By building and integrating often we can validate our changes.
2. Visibility and data are critical factors to successfully steering any project. The same is true for product development teams. Increased visibility enables teams to make educated decisions about what to do next.
3. Catch issues early and nip them in the bud
4. Spend less time debugging and more time adding features

Continuous Integration and Delivery as Organizational Change Agent

When I talk publicly about workforce transformation I often do so in the context of ‘learn by doing’. What I really mean by this is to take something that’s important to the business and drive change around it. In the process generate new value.

Continuous integration is a wonderful place to start to begin the process of breaking down organizational walls. Continuous integration requires that developers begin embracing a QA mindset. They write tests and contribute those tests to integration suites.

Integration test suites are then leveraged as part of the product builds. To do build engineers and operations teams come together to figure out where to host and execute a product build.

Finally once all tests have passed and a new build has been created that artifact is then deployed to production. This requires the important intersection of security, operations and a host of other teams to coordinate and deliver that code to production.

As you can see in this simplified description; continuous integration and delivery takes what has traditionally been a 12-18 month process involving often 100s of people and shrinks it to minutes or hours, in an automated, rapid fashion. To achieve this massive feat organizations must come together and focus on the primary goal of delivery value rapidly to end users.

User Adoption and Value

Now that you understand the fundamentals of continuous integration and delivery both technically and organizationally, it’s time to elevate the conversation to the consumer of the artifacts of this process, the customer.

CI/CD enables us to deliver in small batch sizes, these small batch sizes can be deployed to production environments where users can begin interacting with the software and provide valuable feedback. This new found velocity enables us to embrace the notion of an MVP (minimum viable product). Which gives way to rapid evolution of applications based on feedback from users.

We can now measure user adoption of new features; solicit feedback.

Driving adoption is a continuous cycle that doesn’t end after the first release. It is for this reason that the velocity gain from CI/CD is so critically important. Iterating and adoption to market changes will enable us to stay ahead of our competitors in this rapidly changing world.

Finally

Although this is an overview, introductory article about continuous integration and delivery, it should be noted that almost all new product development embraces this philosophy. Hardly any cloud native project would go without it because we know the benefits it brings in velocity gain and assurance of quality.

We also can infer that companies who embrace CI/CD as a delivery method see software development as a strategic capability that provides competitive advantage. Amazon is a

great example when they first publicized the ability to deploy software to production environments every 11.6 seconds in May of 2011. Despite the fact they have since increased their velocity, expanded their system, added more components etc all made possible by a relentless focus on automation, integration and delivery.

Amazon is not alone; Facebook and Google all release software many times yet so many executives and development teams still remain unconvinced of the benefits.

If your organization or development teams are not delivering software with this mindset then I strongly urge you to experiment so you can see the value it brings to your organization. You may just find you can’t live without it.