VCS and SCM: The Ultimate Guide and 5 Best Practices

A Version Control System (VCS), also known as Source Control Management (SCM), is a way to manage and document changes developers make to software code. The SCM methodology stores IT resources and gives access to all versions of the software as long as these states are saved and offers a comparison between all different versions, making development more efficient and more agile.

In this post, I will explain why we need VCS, provide best practices and recommend a few VCS tools.

In cases where the development process involves only one person, updating code is less difficult. The developer can just update the code and document the changes in a document. But as soon as the development process involves two or more people who are working on the same parts of the code, challenges arise.

In these cases, collaboration quickly became a real headache instead of speeding up delivery, like it was supposed to. The problem lies in the way collaboration is addressed, not in the collaboration in itself. In the process of making collaboration more effective, Version Control Systems was born.

The idea behind the SCM methodology is to prevent and resolve conflicts among developers' codes. Instead of using a file locking approach, Version control system allows contributors to work simultaneously, applying changes on any part of the source codes and even concurrent access. Consequently, contributors can perform parallel changes smoothly.

The VCS methodology is very easy to implement, there are just a few steps to follow.

• Choose a CVS type:
  • Distributed - Each machine used to clone and check out the software will act as a repository
  • Centralized - Centralizes every update on one single server where developers will clone and checkout the source code and will then push back their revision
• Choose a CVS tool.
• Set up the workspace and remote or central repository.
• Share the link to the repository
• Contributors will checkout from the central or remote repository and will start working locally.
• Developers will share their changes to the remote or central repository

In order to use a VCS efficiently, here are some best practices that we recommend you follow.

1. Commit Often

When developing a feature, there are several steps needed in order to complete the whole feature. By committing often, you are ensuring that you are dealing with a small change at a time and it will make it easier to revert if the change introduces a bug or if the change is no longer necessary. It will also help you group your commit in a consistent way. Each commit will contain a particular change.

2. Add a Commit Message

Commit is communication - a commit message is a way to convey a message to other team members. A good commit message should be a short text explaining what was done. Even if it is not compulsory, a commit message is very important.

3. Do Not Push or Commit Uncompleted Work

Even if it is suggested to commit often, this doesn't mean you should commit something that isn't working.

4. Decide on Common Branch Practices

Set a rule when working with branches and stick to it. A common practice should be agreed prior to development and should be followed by each team member.

For example, a common practice could be constantly updating your branches. One of the biggest advantages that SCM offers is the possibility to work on a branch and apply small changes in a given branch at a time. Therefore, updating your branches often will make your integration easier, this will result in fewer conflicts to handle. Updating a branch involves checking out the central or remote repository and integrate changes in current branch.

Another best practice could be creating a new branch for every change, since branches are generally easy to manipulate and to create and this makes management easier. Depending on the type of development it should be clear where developers should derive their working branch from: for instance one main branch where the development of new features starts, another main branch, an image of the production environment, etc.

In general, we recommend using branches as much as possible.

5. Push Source Code to Your Repository (And Nothing Else)

The repository is not a place where you push everything. Only source code related to the project you are working on should be pushed on the repository, it is not the image of your local workspace. Some files should not be pushed on the repository: generated files, workspace configuration, etc.

As you can see, SCM answers many coding limitations:

If you choose to work with a centralized tool, you will need a centralized server that is going to serve all the contributors. Centralized VCS tools are divided in two: a server tool that is installed on the centralized server and a client tool that will be installed in the developers' workstation. Once you have defined your server, you can create a repository for each software project and share the repository link among your contributors. The contributors will just have to check out the repository to retrieve the project and start their development work.

All contributors will share their updates on the central repository; the only way to save changes is to share them.

You can opt for a distributed VCS tool. In this case, you don't need to define a server, and all workstations can act as a repository. The repository in the developer's workstation will be referred to as the local repository and other repositories are referred to as the remote repositories. There can be several remote repositories for a given software project. In practice, there are few common repositories, generally, one per environment that typically serves as a remote repository for developers. There can be some additional rules about the use of these different common remote repositories.

When using a distributed VCS, developers can work and save changes offline and share to the remote repository once the got back online.

There are many SCM tools, and in this section, we are going to see three of the most popular open source SCM tools.

Git

Git is a distributed version control system and is definitely the most used SCM today. Many developers may argue that Git is one of the most difficult VCS and this is somewhat true: it has a higher learning curve, but it also makes branch management a lot easier. Switching between two branches with git does not require the developers to change directory, he or she will just have to ask git to change the content with the branch he or she wants to work with.

In Git, you can choose where to share your change, allowing deployment in different environments easier, too. Git can be used using the command line as well as with a GUI. Documentation about Git can be found here .

Mercurial

Mercurial is another open source distributed version control system and is very widely used as well. This VCS is written in Python and offers useful tools. It has all the benefits of distributed version control system. Compared to other distributed VCS like Git, Mercurial is quicker in terms of learning curve. In Mercurial, each branch will have its own directory so basically switching between branches will mean switching between directories. Documentation can be found here .

SVN

Subversion or SVN is a centralized version control system. SVN is reliable and safe and is used by a large number of developers as well. It is the most used centralized VCS. It is believed to be the easiest SCM but its branch management consumes a lot of resources on the central server. It is a little slower than distributed VCS. The official svn documentation can be found here .

After making changes to your code, make sure you run performance tests to ensure the changes you made didn't affect the way your website or app works. This is also an important part of working in agile.

In BlazeMeter , you can create automated tests that will give you an insightful analysis in real-time and over time. You can also share your tests and results with team members.

Join the Continuous Testing conversation on Slack.