Have You Ever Considered CI/CD as a Service?

Are you interested in creating a complete, fully configured Continuous Integration / Continuous Delivery (CI/CD) environment with a single request, saving you tons of time in configuring and managing the pipeline?

This is the first one of four posts about a CI/CD-as-a-Service solution built on top of Cisco CloudCenter, in a multicloud context along with Cisco Container Platform and Cisco/Google Hybrid Solution.

Continuous Integration / Continuous Delivery (CI/CD)

The main CI/CD concept is continuously making small changes to code, building, testing and delivering more often, more quickly and more efficiently, to respond rapidly to changing business requirements.

The picture illustrates a typical CI/CD process:

Figure 1 Typical CI/CD process

• Continuous Integration

A common practice of frequently integrating and continuously merging code changes into code    repository such a GitLab/SVN. After new code is committed to a repository, the server triggers a “build” and stores the binaries in an artifact repository (such as Nexus).

• Continuous Delivery

The delivery of the build to a run time environment, like Integration, Quality Assurance, Pre-Production where functional and performance tests are running against the application.

• Continuous Deployment

An extension of Delivery, to repeat application deployment to a production environment (private/public cloud), even many times per day. In some advanced scenario, applications are deployed in a hybrid model (e.g. DB on private, front end on a public cloud).

When defining a CI/CD pipeline, you need at least the following:

• A code repository to host and manage all your source code
• A build server to build the application from source code
• An integration server/orchestrator to automate the build and run test code
• A repository to store all the binaries and artifacts of the application
• Tools for automatic configuration and deployment

Let’s take a look at the typical challenges of implementing a CI/CD process. Multiple Line of Business (LoB) and Dev Teams might have different preferred toolset: this is why having a single CI/CD chain in your company isn’t a good option.

Figure 2 variation of CI/CD tools

They might even use different languages (Java, C++, .Net) and be more familiar with a tool (GitHub rather than Subversion).

So the question is how can you accommodate this diversity?

The answer is creating multiple CI/CD chains, install multiple tools (on VM or in a container) depending on the user’s requirements.

However, how much time you will be spending configuring every time, for each LoB or DevTeam, a new CI/CD chain? And what about maintaining and upgrading all the elements of the CI/CD toolchain to be compliant with any new security requirements from your security department?

How long does it take to prepare, configure, deploy and manage multiple CI/CD chains? Sounds like a typical Shadow IT problem, with users potentially rushing to a public cloud to get what they need, bypassing IT. In that case, the solution was to implement automation and self-service to quickly provide the necessary environment to the end users, with the same speed and flexibility as the public cloud.

So wouldn’t it be much easier to adopt the same approach and automate the deployment and configuration of the CI/CD chain?

Good news: that’s precisely the purpose of CI/CDaaS.

Introducing “CI/CD as a Service”

Let us first clarify an important point: we are not discussing relocating your CI/CD resources and process to the cloud, and then consuming from there.

The key things here is that the user (a LoB as for example) can decide what are the tools that will be part of the CI/CD chain. One chain could be composed by GitLab, Jenkins, Maven, jFrog Artifactory another one by SNV, Travis, Nexus.

What we are proposing is automating the deployment and configuration of the elements that are part of your CI/CD Pipeline with just a single request.

Consequently, your users can have their CI/CD chain preconfigured, ready-to-use so they can be more productive.

This means three key benefits for the developer:

1. They get the CI/CD chain that they want, delivered within minutes leveraging the company’s Self Service portal (implemented on top of ServiceNow or Cisco Prime Service Catalog).
2. They get all of the elements of the CI/CD they have selected (e.g., SVN, Jenkins and jFrog Artifactory), automatically deployed and configured to work together without any additional effort required, as opposed to a traditional approach where they would have to configure each element manually
3. They can focus on what matters: creating new features and new applications, rather than spending time in configuring all the elements of their CI/CD chain.

And another three for the IT Ops teams:

1. Every CI/CD chain deployed will be error-free and there will be no misconfiguration. Moreover, IT Ops can now serve multiple LoB (different CI/CD configurations per LoB users/teams).
2. They can still deploy the CI/CD chain wherever they want, as it can run on top of any infrastructure/cloud
3. Less time to do manual configuration, more time to innovate and deliver additional services to their internal customers

Next post will be going through our implementation on top of Cisco CloudCenter.

 

Credits

This post is co-authored with a colleague of mine, Luca Relandini.

References:

CloudCenter
Cisco Cloud Solutions