This week we introduced our learning community called Deliver Better. As the name suggests, it's a learning site for anyone interested in leveling up their software delivery. The hope is to create a learning community for engineers, leaders, and anyone with software delivery stakes to resonate and find content that's useful for delivering better. We currently have an open call to share learning content on delivering better. Click here to sign up and contribute today!

In the spirit of delivering better, today, we'll discuss Version Control Systems and how it extends to software delivery.

Source Code Management, also known as Version Control allows developers to manage and work with their software code. The tool provides benefits for developers as they work on different parts of a codebase, collaborate, and deliver new releases. Source code management done right prevents breaking code changes that are irreversible, and ultimately it serves to improve how developers develop applications together. 

A Guide to Version Control Systems

Version Control Systems (VCS) are tools that provide revision control to allow for reverting, tracking, and correcting software code. Think of a VCS as a timeline for your code revisions. A branch represents this timeline. In the most basic of VCS workflows, you have a main branched called a Main branch. 

You can progress within the timeline by making what is called commits. They are points within the timeline that contains a copy of the current source code that is uploaded or pushed to the repository. The repository or repo holds your version-controlled code as a project. 

A key thing takeaway is introducing more branches that spawn from points of progress on the main branch. It’s common to have a branch for development features. A developer is working on a development feature for version 1.0 of their product, to develop and make changes to the code base without affecting the master branch the developer commits and pushes their changes to a working branch that was a copy of the code from the main branch. Once they are done developing said work, they can merge their branch changes back into the trunk or rather main branch. 

A best practice for using VCS is always to maintain the main branch with clean working versions of your code. Developers that onboard pull down a repository that contains branches of your code, and the default branch is master. Ideally, they shouldn’t spend time finding a different branch and pulling it down to build the application locally on their machine. This workflow is complex for applications that require multiple repositories and branches to run an instance of an application.  

Another common practice is to tag versions of code within the master branch. Then a release can be correlated to a specific tag. And anyone with access to your repository can look up that tag and see that code then. You can also run commands to get the difference between branches or commits made to a single branch. VCSs keep track of who made changes, where, when, within the codebase. 

As a summary, a developer develops on code on their machine, commits their progress towards version 1.0. Once they’re ready to store all their development progress, they push those changes to a branch within a repository. Another developer can pull a copy of that work, branch off of the stable 1.0 version of the code, and make some more code changes on their machine for a 1.1 version. As the application grows and the team scales, they’re able to keep track of source code changes and revisions. 

A Guide on Gitflow and branching strategies

Git is a popular version control system tool, and many other developer tools like IDEs help developers use git to manage their source code. Also, to emerge were strategies for using Git, such as GitFlow. Gitflow is a branching strategy. It became popular because it was a great way to manage larger projects with many contributors, such as open-source projects.

Here is a summary of Vincent Driessen’s original post introducing GitFlow:

• A single repository has two main branches, develop and master.
• The master branch holds the code ready for production release.  
• The develop branch holds the development code. Once the development on the branch is stable and ready to be released, the changes will be merged back into master and tagged. 
• Developers will checkout the develop branch and create feature branches for their development to be merged back into the develop branch. 
• Releases to be deployed will have also belong in a release branch, which will merge into the master branch. 
• Should there be any issues with a production release, a hotfix branch branches off from the master branch, accepts the changes and merges back into the develop and master branches.
• You have to create a pull request before gaining approval to merge back into either the develop or master branches.

And there you have it, a quick summary of Gitflow.

It can be challenging to maintain this structure when you’re starting a project. It can even slow down your software development. The pull request model to merge back into the main branches means that Gitflow requires multiple levels of approval to get to a release. Simplicity is great for greenfield development and for high performing teams to ship quickly.

Trunk-based development and GitHub Flow are alternative branching strategies. The main takeaway here is a VCS workflow is not one size fits all. Pick an approach and optimize/adjust as needed. 

It’s not all about branching

Source code management processes do not negate “best practices” for software development. Nor does it guarantee effectiveness. Here are some considerations to make when working with VCS. 

• Evaluate the project. Determine how your use of VCS lines up with the project and the team. How important is it to iterate quickly? Are you maintaining or starting a project? How is the software delivery performance of the team? Is there a high percentage of change failure? 
• Have VCS rules. Set some practices for the team on how and when to commit. Show an example of a commit message. Establish methods for how you want the team to style commit messages to be informative and consistent. And consider if employing a rule to commit at least once a day makes sense. 
• Determine what gets stored in the repository. Find a structure that works for your ecosystem. Where should you keep workspace configuration or infrastructure as code or other related files? 
• And lastly, consider integrating your VCS workflow with your software delivery. Consider a cadence for tagging release candidates for consistency. At Harness, we deliver every day, so our agile processes extend and plan for that cadence. Target your sprint stories and acceptance criteria for delivery. Features tasks should have completion criteria. Using VCS is a great way to trigger your software delivery pipelines. Yet using VCS does not guarantee you’ll never see any breaking code changes merged into the master branch. Developers should still build and test their changes within their environment!

A major component of delivering better is working with others in a team. Version control systems enable effective code revision and versioning. Use your discussions of VCS to discuss how developers can effectively ship code after a stable version of the code is reached. If you'd like to learn more about how VCS works with software delivery check out our documentation on using GitOps with Harness!