Source Code Management

Source Code Management (SCM), also referred to as Source Control or Version Control Systems, is an essential tool used by software developers for managing the largest and most important asset of software development – source code.

Source Code Management (SCM), also referred to as Source Control or Version Control Systems, is an essential tool used by software developers for managing the largest and most important asset of software development – source code.

As software development organizations such as Realized Solutions create source code for a software system, it’s critical to have a reliable, robust, and secure tool for managing the source code.  It’s critical for both the organization responsible for the software development and RSI’s clients (if different) that uses the software system which is built from the source code, because both can be severely impacted by the loss, theft, or destruction of the source code.  Without the source code for a software system, it becomes extremely difficult, or impossible, to support the system going forward.  A system without source code may work in its current state for a little while, or occasionally even for quite a while, without requiring any changes.  If (and almost always) when an issue comes up making the system partially or completely unusable, without the source code needed to make the necessary change(s) and ‘recompile’ the system, the system essentially becomes dead in the water.

From the perspective of RSI responsibility for the software development, source code management is more than just preserving and securely storing the source code.  SCM software is an essential tool used by developers to facilitate the development itself.  RSI uses Git as its source code management system.  It is a very powerful tool that helps developers at RSI perform various tasks during the software development life cycle.  It is relied upon during requirements gathering and providing answers to customer questions about their systems, feature development, release management, resource planning, defect identification and management, and even sometimes for internal uses such as billing or HR.  The tool allows anyone with the proper permissions to see all the historical changes that were made to a software system within that SCM, including the specific lines of code that were changed and to what files, who made the changes and when, and any associated comments or notes saved with the changeset.

One area that developers heavily is Git during release management.  There are various strategies for using Git or any SCM during release management, and there are pros and cons to each strategy.  In general, RSI uses Git feature branching as a best practice during development and release management for most of our software systems.  There are variations of this strategy within the industry, and across software development teams at RSI, but the general principle is the same.  As individual pieces of work (features, bug fixes, etc.) are created by developers, they are grouped together within Git under the common feature/bug in what is called a code branch, or branch for short.  A branch has as its starting point a snapshot of the entire source code for the system at a given point in time and is then added to with any changes made by the developer(s) associated with the particular feature or bug, and only the changes for that particular feature or bug.  Since it’s possible for many features or bugs to be in progress at any given time, this strategy allows the development team to keep the changes being made for each item separate from other changes.  When the time comes to create the new release package for a system, Git allows developers to easily combine features/bug fixes by picking and choosing which branches should be merged to create the release package.  Git also makes it very easy to get both important high level and detailed information regarding a branch, such as all the changes that have been made on that branch and by whom and when, so the development team can make decisions about which individual items are ready for release, and which items can or should be merged and how.  And if something happens which necessitates that an item be pulled from a particular release, such as due to a bug found late in the release cycle, or a requirements change, Git makes the process of assembling the new release package with the updated set of items typically very quick.