In a blog series about Continuous Integration and Continuous Delivery (CD), I described the process of CI and CD at a high level. In this blog, I will talk about the 5 pillars of Continuous Integration and the tools associated with these 5 pillars. I will explain how the interaction of these tools along with an Agile mindset will help you embark on a journey to continuously deliver value to your customers.
In the final instalment of this blog series, I will share some of my ideas that will help you in the journey towards Shift Left testing. I have used and applied these in various roles across my career.
In the previous blog, I covered the principles of Shift Left testing and also shared an overview about the test pyramid. Now, I will turn to a curated set of blogs and articles to address various problems with each test type described in the test pyramid.
Modern software products are being delivered as a service (SaaS) using cloud technologies. This secular move to cloud and SaaS has changed the way software is developed and deployed. SaaS products give you the means to deliver features and functionality to all your customers very quickly and very often. This also means that any quality issues or outages of your SaaS product will result in large number of unhappy customers. If you look at the root-cause analysis (RCA) of quality issues and defects, you will find that most bugs could have been caught during the design and coding stages. In order to meet the tough quality criteria for SaaS products, we need to test early and test often. This movement towards testing early is what is being called “Shift Left”.
So far in this blog series, we have seen the CI process from a Developer and DevOps (Build/Jenkins) perspective. We have also understood the benefit of using Docker containers for consistency between developers and DevOps system.
In this blog, we will create another docker based Jenkins agent - this time for deployment of an artifact - which in my case is the static HTML version of my blog. The actual deployment step is to copy the files of my static site to an AWS S3 bucket. We could have used a plugin for AWS S3 and directly used the plugin in the Jenkins job to perform a deployment to AWS. But building a customized agent for CD (continuous deployment) gives us the ability to install more tools that might be needed in real world environments. You can install tools like Terraform and Ansible etc and use them to perform more complex tasks.
So far in this blog series, we have seen the CI process from a developer perspective. We have also understood the benefit of using Docker containers for a consistent experience between developers and DevOps systems.
In this blog, I will show you how to use Jenkins as the CI system and build packages automatically. More importantly I will show you how to use the same Docker container image, as used by developers, as a Jenkins agent. This shared use of the infrastructure is important for an effective and efficient CI Process.
It is useful to remember that CI systems and processes usually kick in when developers are ready to merge their code or have already merged their code. So CI systems typically work off the master branch of the source code repository. And the CI process ends with the generation of an artifact. This artifact(s) will be the input for the CD process.
In my earlier blog of the CICD Series, I have highlighted the importance of Docker containers in the CICD process. Using Docker containers, you can create a consistent development environment that can be used by software engineers as well as DevOps systems.
In this edition, I will show you how to convert a Docker container used for development, into a Jenkins agent and yet retain the same experience for the developers. The goal is to show you that developers and the CI system (Jenkins for example) can leverage shared infrastructure and steps to build, package, test, and even deploy the code. This approach reduces environmental errors while creating software products.
So far in the blog series about CI/CD, we have looked at the personas involved in CI/CD and the benefits of using Docker containers to create a consistent environment for developers and Devops practices. In this blog, I will show you how I use Docker and the make utility to execute the CI related steps for my hugo based blogs. Specifically we will see how code is built and tested as a developer. Writing and publishing a new blog is similar to coding and releasing a new feature in a software product. And I will highlight the similarities in this article from the perspective of a developer.
In the blog titled Understanding CI/CD Personas of the series, I highlighted the importance of providing all developers with the same environment to build and test their code. This environment should also be used in the CI systems such as Jenkins for consistent software build generation. In this blog we will see how Docker containers can be used to accomplish this. I will demonstrate how I use Docker for testing my blogs and generating the static HTML files. Note: this blog assumes that you have a basic idea about Docker.
We kick off the blog series about CI/CD by diving deeper into the CI/CD process and looking at the personas involved. Personas help understand the interactions in the CI/CD process. You should also be able to relate these personas to people in your own organizations.