Git version control helps remote teams with integrated builds
Organizations with remote development teams should use Git repositories and Git version control while developing integrated software builds.
With everyone currently working remotely, it's important to make sure that your development teams can work together effectively and communicate often.
Companies should empower remote development teams to move fast, deliver quality and run their applications with confidence -- especially now with business needs constantly pivoting to deliver quicker results to customers. Everyone faces issues around integrated builds -- and consistent core principles should be considered to effectively track code from build to production. This helps ensure software stability despite changes from multiple developers.
Version control systems have fully matured in the last 20 years. Git version control has become the de facto tool of choice for developers on all modern platforms. In the Azure DevOps family, Azure Repos is the version control system. You can use import tools to migrate existing code repositories into Azure Repos, regardless of where your code is now.
When tracking your code from build to production, you should establish your Git repositories by taking into consideration applications that are dependent versus independent of each other.
The following are a few key thoughts to keep in mind when developing integrated builds.
How many Git repositories should you have?
Establishing the number of repositories that you need is key, with your software architecture relating to the granularity of your repository design. If you deploy your entire system together and the architecture doesn't support deploying only a subset of the system, you likely will put the entire system into a single Git repository. Just be aware that a single Git repository cannot be owned by multiple teams.
What should be in your Git repository?
You should store everything you can in your Git repository, with the exception of items that can't be committed to version control systems. Now, this won't be possible with Windows (of course); Visual Studio or VSCode; environment-specific data and configuration; secrets; and large binary files that change very frequently, such as AutoCAD and Revit files. But all other files can be -- and should be -- stored in the Git repository, including:
- Database schema migration scripts
- Azure Resource Manager JSON files
- PowerShell scripts
- Tests
- Build scripts
- Images
- Content assets
- Visio architecture blueprints
- Documentation
- Dependencies, including libraries and tools that don't come from a package manager
How should you set up your Git repository structure?
Consider setting up your directories and files within Git as follows:
- /src: Stores the application code beginning with the solution file
- /Tools: Any tools needed for the build process
- /Build.ps1: The private build script (critical to be in the top-level directory)
- /Click_to_build.bat: A mouse-/keyboard-friendly helper that adds an "& pause" to the build script so that the console window remains open for examination of the build output
- /Open.bat: A mouse-/keyboard-friendly helper that opens the VS solution via a double-click to enter
- /build: This directory is automatically created and destroyed by the brand script. It shouldn't be committed to source control. It is the destination for test/publish output that is temporary.
How do I establish a Git branching pattern?
Choose a branching pattern such as "trunk-based development." As explained in .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, "This branching pattern has a thick master like the trunk of a tree and always growing taller. The branches are short-lived -- short and discreet and tying them to a work item so that every change on the branch is related to the work item." By using a branching pattern, development teams can keep track of each commit, with pull requests used to review each, ensuring that the main branch remains stable during development. The goal should be to combine branches whenever possible as each commit gets approved.
Teams stay on the same page with Git version control
As you work with your remote teams, these core principles are exactly what you need to keep in mind. They apply even as you encounter complex scenarios. Plan adjustments accordingly as you think through your own applications -- but stay true to these principles.
About the author
Jeffrey Palermo is CEO and chief architect at Clear Measure, a software architecture company that empowers development teams to be self-sufficient. He is the founder of the Azure DevOps Podcast and the Azure DevOps User Group; a founding board member of Agile Austin; the founder of AzureAustin; and a leader in the Austin .NET User Group. He is the author of .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, as well as other books and articles. He can be reached at LinkedIn or [email protected].
