Git Continuous Delivery

Software development is hard. It’s OK to admit that. Writing code is very difficult and comes with a lot of pressure, making it a very stressful profession. Ideally, you should always be looking for ways to ease daily pain points of software development life. One way to do that is through automation, which is exactly what Angel Rivera of CircleCI covers in his talk from the 2021 GitKon Git conference.

What is Software’s Purpose?

Angel’s answer to the question of purpose is “software exists to satisfy an end user’s needs.”  This can be done by creating digital services and solutions, which provide fast, reliable, consistent, and secure results, and while this can take many shapes, ultimately and essentially, software automates things. Software facilitates digital representations of concrete objects and physically executed processes, such as turning lights on or off, or in some cases, shopping and paying for things online.

There are many methods and tools to develop software. Tools such as text editors, programming languages, and frameworks are examples of tools that every developer, at a minimum, must have to build software. But beyond that, developers must learn many concepts and methodologies to succeed. There is a lot to learn and it can often feel that the job of software development is endless.

But there is light at the end of the tunnel; there are tools, concepts and practices developers can adopt that can lessen the most difficult and tedious parts of software development! 

Git and Continuous Delivery

Git and continuous delivery are a great pairing that provides immense value when combined. Let’s look first at what role Git plays in the partnership.  

Git is a versioning tool that enables developers to capture and version code changes. Git is very popular with developers because of its small footprint and distributed architecture. With Git, changes can be developed in isolated Git branches; this helps prevent unwanted code or mistakes from being introduced to production. Git gives us a way to experiment with code safely and can help reduce bugs. But if something does go wrong, Git can easily revert the codebase to a safe state.

Manual Git Development Flow and Code Review

A typical developer’s workflow with Git looks something like this:

• You Git clone down repositories to their local environments. 
• You modify the code, working on features or fixing bugs, locally in your development environment. 
• When you hit a milestone, you Git commit those code changes locally. 
• You Git push those code changes to an upstream branch, perhaps to a repo on GitHub. 
• Other developers start a manual code review process.

A manual code review process means developer teams require that someone read and review the code changes that are being proposed or committed before actually incorporating them into a production level branch. Other developers scrutinize the code for things like known bugs, errors, and compliance with coding standards. 

Manual code reviews are helpful and much better than just trusting that if it worked locally, it will work in production, but manual code reviews are also very expensive in terms of time and resources. And since a human is reviewing the code, this process is definitely prone to human error.

Another concern with a manual code review process is how much time it takes to do the review of the code in question, or even get around to starting the review. It could take an hour, a day, a week, a month, or even longer to begin the process of reviewing the submitted code.  And it could take even longer to finish the review.  If the reviewers find any defects, bugs, or errors, the code is rejected and the developer who submitted the code has to start that cycle all over again.  Meanwhile, other changes will likely have been introduced into the project, adding further complications.

CircleCI estimates that, on average, a developer’s time costs about $1.42 per minute. Doing the math, an average code review takes about 120 minutes, and on some teams, 10- 20 developers can be involved. It all gets very expensive really quickly. 

Continuous Integration and Continuous Delivery Principles

Controlling code development and review costs means making code review processes more efficient. Continuous integration and continuous delivery (CI/CD) practices provide a path to making any workflow more efficient through automation.  At the core, CI/CD is essentially the practice of building, testing, and delivering changes to code and user environments using automated tools. 

CI/CD provides us with principles that can be adopted and implemented within software development teams. In the context of Git, continuous delivery and continuous integration principles typically mean that developers will commit code often, to a shared code repository, and test that code on every commit.  

Faster Feedback Loops

CI/CD gives devs a faster feedback loop. Because you are not waiting on human time management to begin the review process, you discover in minutes, or even seconds, if your code is up to snuff. This quick feedback loop lets you fix whatever’s wrong with the code as quickly as possible, ultimately decreasing the time for code changes to reach end-users, fulfilling the goal of software.

Shared Repositories

Git plays a central role here.  One of the core principles within continuous integration is the practice of merging all working copies from each developer on the team to a shared code repository.  Git gives developers freedom to work locally in as many branches as they want, experimenting as much as they need without blocking other users. And when your code is ready, a Git push is all that is needed to integrate their changes in that shared repository.

Deployment Automation

Another part of continuous delivery and continuous deployment is the practice of automatically deploying new software releases to target environments. Not just the production environment where the end user will interact with the code, but also to testing and staging environments.  In the testing environments, testing tools can be deployed to check for errors or other issues, safely away from the other environments.

All the principles of CI/CD really do rely on automation to make them effective. It’s the automation that transitions these principles into reality by defining and executing software delivery practices or processes. 

CI/CD Pipelines & CircleCI

One path to turning these principles of CI/CD into reality is by adopting and implementing a continuous delivery platform, like CircleCI, and building CI/CD pipelines. 

Pipelines are essentially a grouping of things that need to be executed against code to ensure the code is being tested properly. Of course, pipelines need to test if the code compiles correctly, and that artifacts, or binaries, come out as expected.  But there are a lot of other things you can test, like security scans or throughput testing.  Whatever it is that you need to do within your software development review processes, chances are you can automate using CircleCI within a CI/CD pipeline.

The following diagram shows an example of what a CI/CD pipeline looks like visually within the CircleCI platform. 

This is an example of what Angel calls a “happy path,” where everything goes right in an automated code review process:

• The code is pushed up to from a local development environment into a shared branch.
• CircleCI detects those changes and then tests the code.
• All the tests pass, as do the transactions and build jobs within CircleCI. 
• Finally, the changes are pushed to a main branch, ready to be disseminated in the next release cycle.

Of course, not every path is a happy path.  Let’s take a look at that same process using automation and what it looks like when it fails.

In this failing case:

• The code is pushed up to from a local development environment into a shared branch.
• Two of the three tests fail. 
• A Docker image is built, but the code is not deployed. 
• Once the system detects the failure, it notifies the developer of the problem.  
• The developer starts fixing the problem and then runs the whole process again. 

More Automation, Less Manual Problems

Manual processes exist in every development cycle, but there is a lot you can, and should, automate. Reducing the amount of human resources involved in your code review process is one way to help with speeding up your release cycle times, and increase the reliability of your code. CI/CD also means faster feedback loops because testing and vetting code happens automatically every single time it gets committed and pushed.  

Another benefit, perhaps less obvious, is that CI/CD improves overall collaboration around code, leading to better team synergy. Teams function more cohesively when they can stop or catch red flags before they actually happen. Fewer errors mean smoother working scenarios and higher morale. 

For example, let’s imagine a situation where two different developers are touching the same files in a repository. Before they even start working on code, they can collaborate to determine the order of who’s going to work on the code first, helping avoid Git merge conflicts, which happen all the time. Getting manual code review hours off of developers’ plates can go a long way in ensuring they have enough time to collaborate and plan effectively. 

The Right Tools and Automation FTW!

Click here to see Angel walk through a demo of implementing a CI/CD pipeline in CircleCI, automating much of the code review process. 

No matter how you finally implement a continuous delivery strategy, it starts with consistent and clear communication with your team. The team features of GitKraken Client can help you get betting insight into how your team is collaborating. And that’s on top of making it much easier and safer to use Git, while unlocking the advanced workflows Git enables developers on teams of any size.  Start down the path of reduced deployment and release cycle times today and download GitKraken Client!