Continuous Delivery and the Iron Triangle of Software Delivery

The lords of software delivery have always told us that we can pick two out of the three sides of the iron triangle: good, fast or cheap while building and deploying software. Continuous Delivery helps us by never having to make that choice again, deliver on all three and in fact continuously improve on each of them.

Continuous Delivery is the key philosophy, but its foundation is the better-known Continuous Integration (CI). Continuous Integration is the first step of the Continuous Delivery pipeline, it means that every developer keeps their work-in-progress continually integrated with every other developer. Typically this means every developer checks into the mainline at least once a day.

Continuous Integration

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. The main aim of CI is to prevent integration problems by merging code into the main branch more frequently. It is best used in combination with automated unit tests written through the practices of TDD: Test Driven Development. At Achievers, CI has been implemented using the concept of a Pipeline. A pipeline consists of a chain of processing elements (processes, threads, co-routines, functions, etc.), arranged so that the output of each element is the input of the next. We use Jenkins, a cross-platform, continuous integration and continuous delivery application to build jobs to run on a schedule or trigger, as well as thread number of these jobs together to form a pipeline.

Continuous Delivery

Continuous delivery (CD) is a logical evolution or outcome of Continuous Integration and is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. Developers used to a long cycle time may need to change their mindset when working in a CD environment. It is important to understand that any code commit may be released to customers at any point. Patterns such as feature toggles can be very useful for committing code early which is not yet ready for use by end users.

Over the years, Jenkins has become the undisputed ruler among continuous integration (CI), delivery and deployment (CD) tools. It, in a way, defined the CI/CD processes we use today. Software goes through various phases (build, test, deploy) and interacts with a multitude of tools (junit, sonar, nexus etc) on its way to production. Jenkins is the orchestrator that drives the entire pipeline and interacts with each of these tools. Jenkins’ strength is that it has 1200 plugins that let you interact with any of the tools that are in your organization.

At Achievers we have implemented the Jenkins 2.0 pipleline to help us build, integrate, test and deploy to production everyday.

This blogpost here describes in detail the need for a Jenkins pipeline and why it is the best at what it does.

If you are looking to ship code everyday and automate the whole thing, look into Jenkins and what it can do for you.

Amit is a technology leader at Achievers and is helping build the next generation Employee Success Platform. We are aggressively changing how the world works and are always looking for great technical talent to help us build our service while being part of an awesome team.

Click here for career opportunities

.