Continuous Integration

The overall goal of the Cloud Native formula is the shift to DevOps practices, and this section begins to describe how all of these different trends combine to unleash the power of the formula.

As Wikipedia explains DevOps is:

a clipped compound of “software DEVelopment” and “information technology OPeration S“) and is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment, where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

http://cloudbestpractices.net/wp-content/uploads/2017/08/devops.png 496w" sizes="(max-width: 300px) 100vw, 300px" />This goal of increasing software release frequency is the headline message and is why the approach typically goes in hand in hand with the adoption of Continuous Delivery best practices:

“an approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. 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.

DevOps Toolchains

As the name suggests the goal of a ‘toolchain‘ is to define a collection of different tools, used together to achieve some broader process activity, in this case is key to making possible this higher frequency of software releases by better connecting each step in the cycle.

Given the mix of development languages (Java, .NET etc.), skill levels and existing in-house apps, this combination will vary between organizations, and there are also a plethora of tool options to choose from. For example in the Wikipedia entry for open source configuration apps alone they list numerous options, and also they make the simple but crucial point:

“Not all tools have the same goal and the same feature set.”

Netflix again provides the perfect poster child example for explaining what and how this toolchain is formed, identifying their combination which includes their own Spinnaker tool, and where and how each tool is used in the overall software lifecycle. (Read more in this detailed Netflix case study.)

http://cloudbestpractices.net/wp-content/uploads/2017/08/netflix-spinnak... 300w, http://cloudbestpractices.net/wp-content/uploads/2017/08/netflix-spinnak... 768w" sizes="(max-width: 829px) 100vw, 829px" />

Popular tools for this goal include Jenkins, a centrepiece foundation for Continuous Integration practices, and Ansible, which can be combined with other tools like Puppet and Chef to define a DevOps recipe, and in this era of Cloud-driven plenitude there is almost no end of possible permutations.

Other tool chain combinations highlight additional dimensions:

• In their white paper Continuous Testing for Continuous Delivery CA defines the role of Testing within an overall Continuous Delivery pipeline.
• Extensions are available to target deployment to specific Cloud providers, such as deploying from Github to Azure.
• xMatters integration with Zendesk to link issues to support communications.

DevOps Integration Hub

Other vendor examples offer the full integrated suite, such as Tasktop’s Integration Hub.

As they suggest in their blog one of the key bottlenecks constricting the throughput of DevOps teams is the lack of integration between the different tools used to complete the software development lifecycle. So they have suggested the need for a general solution category, a ‘DevOps Integration Hub‘ as a particular fit for this need.

They offer a DevOps Integration suite that can be used to build linked permutations such as:

• Exposes their Tasktop integration platform with a modern webhook, REST and JSON based integration layer that will allow any DevOps tool to be connected to the software lifecycle, such as Selenium-based test execution to Agile planning tools.
• Jenkins integration for flowing build information to user stories or requirements, as well as Github and Gerrit integration for automating change set traceability.

They describe how the 1,000 strong Bosch team have achieved a unified tool chain that funnels 2,500 feature requests a month from electric car innovation programs, into a single dash board for developers to prioritize and action.

Furthermore by tying together Jenkins with the automation to burn Flash ECUs they have empowered the team to work around a true end-to-end Continuous Deployment lifecycle.

It’s a very powerful metaphor when you consider how literally it enables sharing of best practices. High velocity team processes that have been developed by a real team, encoded into the application patterns they use to achieve them, is a big building block for enabling this.

Open Source DevOps

There are also a wealth of open source options for building a toolchain. Described in this blog is the news Accenture open sourced their own DevOps design and tool set, and also an overview for how you can repeat your own implementation of their powerful model.

‘ADOP’ – Accenture DevOps Platform is:

a framework that glues together a suite of open source development tools and provides a really quick way of mobilizing software development projects in a consistent way, using a standard set of tools and processes (for example, Continuous Delivery). The framework can be configured for use for a particular technology using a ‘cartridge’.

ADOP is mainly a set of Docker-composed templates which provision a suite of DevOps tools, but along with the insights shared by Martin Croker the pioneer behind the idea through his blog, also constitutes a repeatable design recipe if you too want to implement a DevOps model for your organization.

In particular is the key blueprint design idea of ‘cartridges’, implemented through the core Jenkins foundation.

The key business benefit to note is how Martin describes an implementation of the environment can be stood up quickly in response to new client engagements, not only supporting those teams with agile processes but also ensuring they then follow defined central governance for DevOps practices, from the start.

Martin explains more in this video.