Run massively scalable performance tests on web, mobile, and APIs

Request a Demo
May. 27th, 2018

VCS and SCM - The Ultimate Guide and 5 Best Practices

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, 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 blog post, I will explain why we need VCS, provide best practices and recommend a few VCS tools.

 

Why We Need Source Control Management

 

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.

 

  • Frequent Code Regression - Discarding the works of other developers can happen very frequently, resulting in a high risk of regression each time a new change is made. Even if all developers start with the same version of the software and even if they all work on different features at a time, as soon as they commit their revision they will be prompted to make a choice between their current revision and the ones in the repository. The risk to end up with the wrong revision is high and may result in a regression in the software's behavior. Moreover, the more developers working on the same project the more risk there is to have one or more contributors working on an old version of the software containing unresolved issues.

 

  • Reduces Development Velocity - Since it is hard to tell which revision should be kept, the chances of deleting others’ work are enormous. Without VCS, a software development team is very likely to redo the work over again and often. In the attempt to advance faster, by involving additional developers, for instance, the risk factor increases. Without a way to track changes, any change made has a great risk to be discarded by the following update. When trying to advance, we may be taking a step backward instead. This will limit the speed of software delivery. This also discourages collaboration: concurrent code accesses will most of the time end up with lost changes. Knowing that working with other team members may mean that you have to redo the same job over and over again, and this will make developers question the collaborative approach.

 

  • Reduces System Maintainability - No tracking of code changes makes it hard to tell what may have caused a bug or a regression, making it difficult to fix the system and advance it.

 

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.

 

5 SCM Best Practices for Efficient Use

 

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.

 

Version Control Management Advantages

 

As you can see, SCM answers many coding limitations:

 

  • All changes are attributable: there is no longer a mystery behind a change, a deletion and so on. Each commit is linked to a user and whenever there was something unclear in the code, whether it is a lack of documentation, a code deletion etc. you can tell who was to “blame” and you can always know to whom you should or have to turn to.

 

  • Everything can be tracked and reverting is made easier: every single change made on the code is tracked, from a single space included, code formatting or anything else. If a change made proved to be useless or too buggy, it is always possible to revert to an earlier version, or to any version.

 

  • Better conflict resolution - since every change is tracked, you can know for sure which codes were introduced and why. According to the requirements, you can tell for sure what to keep and what to discard during a conflict.

 

  • Easier code maintenance and code quality monitoring: VCS provides co-changed analysis tools and helps identify files and folders modified at the same time. It can be used to monitor weak architecture. Every change belonging to the same revision can be identified. An indicator of strong dependency would be a frequent change in other codes when one part of the code is updated and vice versa. It then offers a good approach to rethink the software architecture if needed. If a little change in a part of code causes changes in several parts of a code very often it may indicate a maintainability issue. Strongly coupled modules or codes can be harder to upgrade.

 

  • Less software regression: You should update regularly your current branch. One best practice consists of a regular update during development, and a last update before sharing the revision. It ensures that branches are always up to date. Working on an update revision will help you ensure that you are not going to integrate already fixed bugs once you are done with your work. Your change may not be flawless, however, you will be sure there won't be a regression.

 

  • Better organization and a better communication: All changes made are explained using human language when committing a change; these explanations are called commit messages. Even when the team members are working in different places, they can communicate via commit message. Commit messages are not only a communication with other developers, they will be useful when you come back few days or a few weeks later and you have forgotten what changes did you make. SCM helps you organize your work better and enhances communication.

 

Distributed vs. Centralized VCS

 

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.   

 

Recommended VCS Tools

 

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.

 

Performance Testing Your Code with BlazeMeter

 

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..

 

To try out BlazeMeter, request a demo, or put your URL in the box below and your test will start in minutes.

 

Join the Continuous Testing conversation on Slack.

     
arrow Please enter a valid URL

Interested in writing for our Blog? Send us a pitch!