Planning a new software version, also known as release management, is in many respects a challenge in software developing. It takes several time consuming steps to prepare the new version (release): collecting and prioritizing requirements, precise time scheduling for the implementation of features or bug fixes, a set time frame for quality management and the test phase. For features and bug fixes, project management tools or ticket systems are the best solutions. Support staff can collect the requirements from inquiries of customers or employees.
These work packages will then be prioritized by project managers and developers, they estimate expenditures and integrate features and bug fixes into the release planning. The implementation of these work packages brings another challenge: revision control. Revision control should be used to prevent conflicts since different developers work together on the same projects and therefore on the same data.
Revision control offers the following advantages:
Backup: the source code will be saved at a central storage location and therefore automatically and securely stored.
Difference: a good revision control can display the difference between two commits. It is possible for a developer to make changes to a previous commit.
Merge: Since collaborative work also means that several developers modify the same data, it is necessary that a revision control assists the developers when bringing the data together.
History: to understand the changes between two commits, revision control can display the differences on a line by line basis.
Revert: it is always possible to return to a previous commit and undo individual changes
Blame: every time a developer modifies a data and places it in the version control system, the user will be saved. It is thus possible to classify every modification to a user.
Branch and merge: under revision control sets of files may be branched (branching). Modifications can be made in this branch and then later be remerged with the stem (merging). However, during this time the stem itself may have been modified as well, in most cases this means both data sets need to be edited manually.
Tag: many revision controls allow the labeling of specific revisions. Tags are, unlike revisions, lingual and therefore easier to record and to recover. It is thus possible to label an internal revision term such as ‘r3921’ or ‘4f37029…’ as for instance ‘Release-1.1’.
Hook: many revision control systems can execute scripts before and after certain actions. It is therefore possible if for example a new revision has been made available to send out an email to all developers containing all modifications.
The most commonly used revision controls are free of charge, e.g. CVS (Concurrent Versions System), Subversion, GIT and Mercurial. There are also many proprietary systems such as MS Source Safe or MS Team Foundation Server. All systems can be divided into two groups: central and distributed revision control systems. Distributed revision control systems are considered to be a derivative of central revision control systems, they have emerged due to increasing networking and the way software projects are done nowadays: in different locations by employees and freelancers. With the help of branching and merging, which are both based on the graph theory, clear processes for the development of features and bug fixes can be defined.
It is thus possible to work on packages in a simple and structured manner, and to later separate them in a team. The usage of distributed revision control systems improves the release and project management for spatially distributed or local teams significantly. Compared to centralized systems, distributed control systems enable the developers to switch fast and easily between different work packages or if they were given a higher priority by the project management to complete them first and then go back to their previous work, without any losses or time consuming backups.
Distributed control systems simplify release management since individual work packages can be directly selected in the revision control and integrated into a release. A complete history of all integrated packages is visible to every project participant. Work packages, which have not been integrated into a release, can easily be preserved until the decision allowing its integration is made.
Moreover, revision controls allow an automatic deployment, making it possible to integrate one’s own scripts that perform all actions for a deployment in the desired scenario. In summary, together with a good branching concept and supported by a defined release management distributed control systems improve the work within and between teams. This also has a positive effect on software quality and last but not least the error susceptibility decreases significantly.