The Agile Scrum methodology suggests that small scrum teams are more effective in attaining their goals. Amazon’s two-pizza rule also highlights the benefits of smaller teams. The underlying principle is that small teams lead to better collaboration and more agility in execution. There is also a mathematical and social basis for the effectiveness of small teams. In this blog, we will explore the Dunbar numbers and see how these numbers related to the size and effectiveness of software development teams.
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.
If you or your team is trying to adopt CI/CD and struggling to understand what CI/CD is all about, then you are not alone. CI/CD stands for Continuous Integration and Continuous Delivery. In a cloud environment CD also encompasses Continuous Deployment because you deploy code as soon as it is ready. If you aspire to be agile, then you need to embrace CI/CD wholeheartedly.
I will share a couple of great articles that introduce CI/CD. Instead of me providing yet another definition, I recommend that you read these articles. But here is what I will do. Using a series of blogs, I will take you through a journey of CI and CD. I will use my blog as an example to show various technologies like Jenkins and Docker and their role in CI and CD.
If you are associated with the high technology (Software) area, you know the importance of reading and practising new technologies. This is all the more important for new college graduates. With that in mind, I am recommending a three books to new college graduates who aspire to succeed in the technology industry. I have read these books and I feel they can be useful at any time in your career.
After a long hiatus it is time for the semi-annual update about my blogging and learning goals. Clearly I have been late on this blog itself and it should be an indicator of how the rest of the year is going to be.