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.
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.
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:
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.
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.
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!
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.