Source Control in Azure DevOps (Best practices)

Why Source Control?

Software development requires writing code.

Once the code is written, it needs to be kept safe (so code is not deleted or corrupted) and for that, we maintain a copy of it. Sometimes, we make fixes to code that does not works as expected. As a precaution, the original code is kept along with the changed code. If the changed code works, we do not need the original code, but in case it does not work, we can always use the original code to start fresh and remove bugs.

This entire process creates many copies of our code. Even if we name these copies (or timestamp), it becomes very difficult to keep track of them.

There is also a chance that our machine, on which the code is created, may crash and we may end up losing all code that was written. For team members, this becomes a bigger challenge if multiple developers are creating, maintaining and working on separate copies of the code.

There should be a way in which all team members are able to collaborate and work with the same codebase.

Enter Source Control which helps in removing all the aforementioned problems.

What is Source Control?

• Version Control is a term used interchangeably with revision control or source control. So hence forth I will use the two terms source control and version control interchangeably.
• Source Control is a way to keep a common repository of source code for multiple developers in a team. Multiple team members can work on the same code, so sharing of code becomes easier.
• Source Control helps in tracking and managing changes made to the code by different team members. This ensures that Team members work with the latest version of code.
• A complete history of code can be viewed with Source Control. We may have to resolve conflicts when multiple developers try to change the same file. History is maintained for all the changes, including any conflicts resolution. Source and Version Control terms are used interchangeably. But Version Control also takes care of large binary files.
• With Source Control it becomes easier to keep track of the version of software which has certain bugs. These different versions can be labelled and kept separate.

There are many tools for source control. It mainly comprises of two types of source control – centralized or distributed. Examples of Centralized version control tools are:

• Azure DevOps – TFVC (Team Foundation Version Control)
• SVN – Subversion
• CVS
• SourceSafe
• ClearCase
• Perforce

Examples of Distributed version control tools:

• Azure DevOps – Git
• GitHub
• GitHub enterprise
• Bitbucket
• Mercurial

Best Practices of Source Control

Check in/Commit early and commit frequently
Ensure that the files you are working on are with latest code. You have a roll back facility for any commit you do.

Check in/Commit logical code change
Any logical problem encountered and modified needs to be committed so as to help other team members aware about it.

Provide descriptive and useful messages with check ins/commits
Providing proper messages will ultimately result in understanding the code better.

Avoid checking in or committing of in complete work
If incomplete code is checked in or committed, there is always a chance that some team member may use the code and build some functionality on top of it. It may result in a cascading effect for a bug or issue

Always unit test before check in/commit
Unit testing helps in understanding that the functionality is ‘actually’ working as expected and is not just merely free of syntax errors.

Use proper branching strategy
Branches help in team development but if we clutter the source control with a lot of them, we may end up with more problems than solutions. It is recommended that you design a branching strategy which suits your need (Eg: GitFlow branching strategy and so on).

Do not check in/commit code without review
Any developer may inadvertently end up making some mistakes which can be discovered during code review. This will result in fewer bugs at a later stage. The compliance policies can also be checked and applied at this stage (like naming conventions, using specific names for classes and methods etc).

Database related artefacts should also be versioned
Stored Procedures, User defined functions (UDFs) are changing continuously and must be versioned so as to roll back if required.

Source Control Management by Microsoft

Microsoft provides both types of source control management with Azure DevOps or Azure DevOps Server 2019 – Centralized as well as Distributed.

Centralized version control comes with a tool called Team Foundation Version Control (TFVC) and for Distributed version control, we either have Git implemented with Azure DevOps or can even use GitHub with Azure DevOps.

Team Foundation Version Control (TFVC)

In TFVC, all the team members work with only one version of files(s) on their machines. There is a history of code only on the server-side. All the branches get automatically created on the server.

TFVC has two kinds of workspaces, server and local. With server workspace, the code can be checked out to developers’ machines, but a connection to the server is required for all operations. This helps in situations where the codebase is very large. With local workspaces, a team member can have a copy and work offline if required. In both the cases, developers can check in code and resolve conflicts.

Git

Each developer has his/her own copy of code to work with on their local machines. All version control operations can be available in local copy and can execute quickly as no network is required.

The code can be committed to a shared repository, when required. Branches can remain local and thus can be light weight. We can keep minimum branches on the server so as to keep it less cluttered. The local branch can be reviewed later using a Pull Request and can be merged on the server.

Difference between TFVC and Git:

Just having different source control tools is not enough, we also need to know how to use them optimally.

Source Control related Features in Azure DevOps

Before we get into details of the best practices of source control in Azure DevOps, let us have a look at various other tooling features available which will help in many ways.

Azure DevOps provides us with work item tracking. If used properly, this feature will be able to get a tracing from requirement – to code – to test case – to the bug raised. In short, for a bug, we will be able to find out the requirement associated with it.

• For achieving this we can spawn requirements to multiple tasks
• Provide one or multiple test case to test the requirements
• Create bug associated with Test Case when test case fails
• Associate code with work item at the time of checking code or committing code

Visual Studio provides us with an excellent UI for writing code. It also provides support to various test framework other than MS framework.

• We can use this support to write unit test
• Along with MS Framework, developer can write unit tests with NUnit, xUnit

Azure DevOps provides pipelines with which Continuous Integration (CI) and Continuous Deployment (CD) is possible with ease.

Best Practices of Source Control in Azure DevOps

#1. It is always a good practice to associate code with work item at the time of check in/commit. This will help in getting traceability from requirement to tasks and the tasks in turn will be associated with code.

Visual Studio provides us an interface for doing the same.

This way, when the test case is tested and a bug filed, it can be traced back to the requirement.

#2. Provide meaningful and useful comments with check in/commits

• “Fixed it” or “done” are not helpful in the long run
• A comment should be able to help in maintaining code

#3. Use Code Review with TFVC check-in and Pull Request with git commit

• Code Review will ensure that the code will not be checked in before reviewing it
• Pull Request (PR) will help in committing quality code to the repository

#4. Visual Studio provides support to various testing framework along with MS framework. Use them.

#5. Use Build Triggers effectively

• With TFVC, Gated Check-in will ensure that the code which cannot be merged with new code on the server, will not be checked in
  • As the name suggests, the code will not be directly checked in, but first a private build will execute on the server with the code to check-in, and the already available new/latest code
  • If the private build completes without any issues, code gets checked-in
  • If the build is not successful in an IDE like Visual Studio, the developer gets a message that the code cannot be checked in
  • The developer takes care of the problem and tries to check in the code again
• Using Pull Request with Git will help in achieving same result as Gated check in
• Using Continuous Integration (CI) trigger will take care of automatically triggering the server-side build and will also take care of Build Verification Tests (BVTs)

#6. Use Release Pipelines Triggers effectively

• With the help of Release pipeline, we can provide a Continuous Deployment (CD) trigger
  • This will automatically deploy artefacts to specified environment once the build gets completed successfully and artefacts are available
• We can define multi stage pipelines where there can be two separate targets for deployment
  • This can be Virtual Machines, Web Server, on-premises machines or by using deployment groups
  • The stages can be with different triggers and with pre-deployment conditions for deployment. This can be with respect to automated deployment or manual (after a group or person gives go ahead)
  • The stages can be cloned to keep similar tasks but the configuration can be different
• The release can be directly associated with source control to multiple branches. In this scenario, we can eliminate the build artefact but directly use source control branch to trigger the release and go ahead with deployment. A filter can be used to select specific branch.
• A Pull Request can directly trigger release
  • Use a PR as an artefact in the release pipeline
  • Set up branch policy for the release pipeline

Conclusion

In this article, I wrote about the importance of Source Control, as well as different types of Source Control.

I also covered the various Best Practices of working with Source Control by using tools available in Azure DevOps.

This article was technically reviewed by Subodh Sohoni.

This article has been editorially reviewed by Suprotim Agarwal.

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

Author

Gouri is a Trainer and Consultant on Azure DevOps and Azure Development. She has an experience of three decades in software training and consulting. She is a graduate from Pune University and PGDCA from Pune University. Gouri is a Microsoft Most Valuable Professional (MVP)  - Developer Technologies (Azure DevOps), Microsoft Certified Trainer (MCT) and a Microsoft Certified Azure DevOps Engineer Expert. She has conducted over 150 corporate trainings on various Microsoft technologies. She is a speaker with Pune User Group and has conducted sessions on Azure DevOps, SQL Server Business Intelligence and Mobile Application Development. Gouri has written more than 75 articles on Azure DevOps, TFS, SQL Server Business Intelligence and SQL Azure which are published on www.sqlservercurry.com and www.dotnetcurry.com. You can connect with her on LinkedIn.