Version control system and web integration projects
Why does a version control system increase quality levels in a web integration project? What are the advantages of using such a system? And what is its overall influence on development?
Also, you should not miss the previous part of the article series about web integration – Advantages of continuous integration and automated deployment from the perspective of web integration. It is a must-read!
The Version Control System (VCS) plays an important role in the development of a web integration project. When using VCS, the main goal is to record the changes in project development and support for team collaboration, and deploy an application to various environments. Modern versioning systems resolve not only the issue of cooperation and recording changes, but also bring a range of other benefits.
VCS supports tools for continuous integration, such as Jenkins, Hudson, Bamboo. They can help us automatize application testing and deployment. Ultimately, tests and reporting will be followed by reporting in the form of email or other notifications.
Features of the most popular version control systems
Traditionally, Subversion (SVN) is the client-server application, which for a long period was the dominant system in terms of revision management. SVN saves space and uses different revisions. The project is versioned on a central repository on the server. For versioning, a functional connection with the service on the server is vital.
A similar philosophy can be seen in the Git and Mercurial distributed systems. The main difference between these systems and SVN is that all developers can work locally and do not require server connections to do their work. Additionally, they may submit only part of their work on a remote server and retain other parts locally for later adjustments.
Git is very flexible, involves a whole set of single-purpose tools and can easily be upgraded. Among others, we use Gitflow. In contrast, Mercurial is a single, compact library and has shown itself to be rather inflexible. For a detailed comparison of git and Mercurial, please refer to the Git vs. Mercurial article.
Decentralised nature of development, with a central repository
The project evolution results from a basically decentralised scheme. All developers work on their own local copies of the project and in specific teams in separate locations. Different teams use their local environments for developing and testing before a specific batch of changes is shared with other teams. As the number of teams and developers grows, so does the risk that two developers are involved in the same part of the application and the adjustments made will be incompatible. The distributed VCS is a better solution to such problems.
There are many approaches, either centralised or decentralised, which can be dealt with by various types of model (e.g. Workflow).
A unified system and standardisation of development
The settings of a unified form of changes versioning and a system of submitting work creates rules for the developer’s work, and a firm foundation for standardisation of development and distribution. For developers, this means clearly defined processes and, as a result, a set of instructions for dealing with possible situations that could arise.
Updating the application in various environments poses problems in the absence of VCS. In practice, we make use of continuous integration, using tools connected with VCS.
The project launch, and updates in operations in the testing and production environment, is further simplified, reducing the costs of handing over work and inspections.
To hire services or use your own
A versioning system can be operated on your own server, a solution which offers the maximum configurability. In projects where sensitive client data is processed, it is also imperative that the source codes are not made public, with an arrangement that under no circumstances could anybody other than the responsible developer be allowed access to such data.
If we do not want to deal with an operating a versioning system, we can use specialised hosting services supported by a selected versioning system. Github supports use of Git and SVN in parallel, giving the developer the freedom to choose the versioning system.
Migration between services
Everything progresses. In the past here at Krcmic.com or at Onlineandweb.com we operated our own SVN server and Git server. But despite its benefits, we had to move on and hand over to hosting services.
The first migration involves the transfer from our server to GitHub. Later on we moved our projects from GitHub to Bitbucket.
Moving repositories to GitHub
Migration on GitHub involves just a few simple steps.
- Create the repository on GitHub.
- In the original location on our server we configure as remote the repository that we set up in point 1.
- The entire history is sent to the remote repository.
- Security is configured for the developer team, and we inform its members about the migration carried out.
That is it. Then, work on the project can continue on without interruption.
Transfer from GitHub to Bitbucket
Thanks to import, the project need not only be migrated between GitHub and Bitbucket. This is a convenient method, where with the help of a single form a repository is created on Bitbucket. In addition, a request is made for information needed for access to the original repository on GitHub.
As can be seen, this form of migration is even easier than a switch to GitHub.
Blending versioned and non-versioned parts of the application
In virtually all web integration projects, there are parts that we do not want to version. Developers need local settings for a variety of environments (for example settings for a database connection). At the user level, we have user-managed data, through a Content Management System (texts, images, video…). Such parts should be separate from a versioning system. There is no need, for both security and purely practical reasons. In addition, the user data has a very large volume. Versioning is problematic at the very least, and in most cases is simply not possible.
In projects we resolve the situation through placing of configuration files and data folders in a list of ignored parts of the project. In Git, such a setting has the file content marked .gitignore, where specific files and whole can be specified and rules can be set for ignoring folders parametrically (for details see GitHub help and others).
Positive impacts of the version control system on the development of a web integration system
Version control system in the life cycle of a web integration project has an immediate impact on several areas:
- Collaboration of developers, who tend to be in separate locations and focus on different professional areas;
- responsibility linked with the traceability changes to the application codes,
- secure deployment – the option to go through the changes history allows us return to a previous, stable version, if updating appears unsuitable for the operating environment;
- documentation – records from a versioning system complement the traditional developer documentation and also add a time dimension, thanks to which it is possible to retrospectively monitor the speed and robustness of the development. Data export can be turned into graphic format, which will be especially appreciated by non-technical people in the team.
- audit – after completing the project we turn to the versioning system audit of project,
- change log – a summary of all changes for a particular period can be produced according to history.
Advantages and disadvantages – a summary
Version brings certain disadvantages, including an undoubted increase in levels of labour-intensiveness. Developers are required to extend their training to cover new tools that they will need for their work. On the other hand, versioning requires minimum effort in comparison with the development of web applications. Practice shows that the overall level of labour intensiveness does not increase in project development. They will therefore cut deployment costs, and development in turn is made more effective.
The increase in quality levels and effectiveness in development as a consequence outweighs the disadvantages. As well as the technical aspects outlined above, mention should be made of the audit option, which is also appreciated by managers.
The above clearly shows that using a versioning system should be included in the development of every web integration project.
You can now follow to the next part – article called: Front-End Task Automation – Part 1.
Was this article helpful?
Support us to keep up the good work and to provide you even better content. Your donations will be used to help students get access to quality content for free and pay our contributors’ salaries, who work hard to create this website content! Thank you for all your support!
Reaction to comment: Cancel reply