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.
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
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).
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.
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:
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 ishow 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.
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:
And another three for the IT Ops teams:
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