CI/CD/CD
Continuous integration, continuous development and ANOTHER CD? Is that a typo? No my friends, in a truly DevOps fashion, there are two CDs that are treated interchangeably when they really need to be set apart from each other as their own processed. If you want to be truly bleeding edge and match the productivity of large corps like Amazon, Facebook and Google - hopefully not match their arguably unethical coding practices - the you need to embrace all three facets, including the final CD which is seen as somewhat of a unicorn in industry right now even though it is gaining levels of normalization at select firms. So what are all three tenets?
Continuous Integration, Continuous Development and Continuous Delivery
Lets walk through each of these steps with the specific open source tools and the use case of each of them in the process.
Continuous Integration
Tools
Git, Gradle, Jenkins, Docker, Sonar
What is it
CI is the practice of integrating multiple branches and features of code into a single golden pre-production repository branch that I like to call the “develop” branch. This branch need to be free of too many mistakes so you’ll need to mitigate problem as much as possible before they reach this branch.
How to use the tools
Use some git service to help manage code so that it’s not locally being managed by users (this is pretty archaic, but I’m saying it for posterity). Always merge in the develop branch to your feature prior to pushing.
Gradle can be utilized to create or override tasks that will help your flow. For example, building your project, generating test reports and even using custom plugins to validate that your feature has the latest commits from the develop branch integrated.
Sonar should at a minimum be utilized to validate test coverage and check for code smells. Whatever else it provides should be integrated by your team as you find it necessary.
Docker is brilliant in continuous integration because it can take your pre-created images and run them on any hardware where the docker engine is installed. It’s a bunch of mini-VMs that can be spun up and down with little consequence to anyone. If you needed to test that service A is correctly calling service B, you could spin them both up on your machine and test across localhost.
Jenkins is the big daddy of this whole process. All these tools above would still require you to run each step manually if you didn’t use Jenkins to run them for you. All those commands you run in the CLI? Jenkins can do it for you. It can run your Gradle commands, stop your pipeline from merging upon test failures or reports from Sonar, and even create and deploy Docker containers (that’s a sneak peek for you to the continuous deployment section).
Continuous Development
Tools
Git, Gradle, IDE, Clubhouse
What is it
This ephemeral step is more so on team leads to create for their teams. An environment needs to be created that allows ownership of tasks and awards self-sufficiency. In short, it’s being in an environment that allows you take on tasks, well, continuously without being blocked by other developers, technical roadblocks, etc.
How to use the tools
Any git tooling can be used to have repositories easily clone-able and branch-able for any developer on the team. Beyond that, be sure to commit and push often to the feature branches and save your work, and have easily accessible code review tools.
Gradle can be used to run tests locally and when merge requests are created (with the help of Jenkins as stated in the CI section) and ensure projects are building correctly, even before a merge is needed.
I feel like the IDE is obvious here, but it works really nicely if everyone tries to keep their settings agnostic of an IDE so no folks are tied in to a specific tooling here. If you must know, IDEA IntelliJ is the way to go ;)
Clubhouse will be the bread and butter of continuous development, and it has a very liberal free plan for small teams. Add clubhouse to your agile strategy and you will have increases in efficiency that you never thought possible. Use clubhouse to break down your tasks and see a very powerful but simple kanban dashboard that can be easily managed by folks who are even new to the program. Create your tasks so that their as simple as possible and not blocking each other (easier said than done) and motivate developers to pick up tasks as they’re completing others. Code review can be a big blocker here too - it’s much better if you’re able to use pairing to avoid it, but going and deeper on this topic would warrant its own blog post.
Continuous Deployment (or Delivery)
Tools
Git, Gradle, Jenkins, Docker, Kubernetes,
What is it
The final CD is somewhat of a unicorn to achieve. If I was a betting man, I’d wager that less than 10% of production apps have true continuous deployment. What this would mean, in a perfect world, is that we get rid of change management meetings where all changes to the applications are approved at some scheduled rate and instead trust that the developer and their pairs or team leads have done the due diligence to deploy code not just to the develop or QA environment... but all the way to production shudders.
How to use the tools
Git, Gradle, Jenkins, and Docker uses have been identified in the above sections and apply the same to this section.
Kubernetes is a game changer when we get into continuous deployment though. It hosts a plethora of in-built functionality that will make you forget why you ever deployed apps manually. Use it’s abilities to deploy new applications and updated features, re-deploy failed applications, set automatic scaling, and anything else you can think of. This is great in production, but might be overkill in a development or QA environment where you can get away with something simpler like Docker Compose.
Brining It All Together
I’m sure you’ve noticed an overarching theme across all three of these stages, but in case you missed it let me hit you on the head with it.
Automation
For truly achieving a CI/CD squared flow, you need to implement automation across the whole tool chain of integration, development, and deployment (or delivery, whatever you want to call it). The tools and use cases above are only examples of what you can do with the right tools - especially open source ones.
I challenge you to implement as much of this as possible in your projects and teams. Go forth!