Source Code Management: An Introduction

Source code management is the practice of tracking modifications to source code. Keeping a running history of the changes made to a codebase helps programmers, developers and testers ensure that they’re always working with accurate and up-to-date code and helps resolve conflicts when merging code from multiple sources.

Source code management TLDR

Source code management is important because, in work environments, multiple developers work in a shared codebase at the same time. With each developer working on a single feature, one dev could unknowingly make conflicting code changes — or one developer’s saved edits could overwrite the other dev’s changes.

Before source code management became widespread, few safeguards existed to prevent these scenarios. Each time a developer started work on a file, they could let teammates know to ensure no one else was working on it simultaneously. This was hardly foolproof. And when it worked, this method left no record of all the changes made over the course of a project — if a change resulted in a bug, there was no way to trace where it originated or determine how to fix it.

Source code management solves these problems by:

• Tracking each developer’s changes.
• Highlighting conflicts.
• Preventing code overwriting. 

Developers are alerted to any conflicts so they can address them before they are merged into the source code and potentially compromise the application. In the sections that follow, we’ll take a closer look at how source code management works, what benefits it brings to software development, and which best practices to follow to get the most out of the process.

---

---

How source code management works

The heart of the source code management process is the code repository, a centralized server that stores all of an organization’s code as well as the source code management system that tracks code changes for various development projects.

Copies of source code are stored as individual files. Developers “check out” a file when they want to make code revisions and receive a copy of that file in their local environment. At the same time, the original file in the repository is locked so that no one else can check out that piece of code and inadvertently overwrite the current developer’s changes.

After the developer makes and tests their changes, they “commit” them, saving the revised code to the repository. This replaces the original file, increments the code version number — a process called “version control” — and removes the lock.

The process is repeated every time another developer makes code changes to any file. The source code management system then stores and manages all revisions to maintain a complete history of each piece of code.

Regardless of tools, source code management uses an array of common terms, including the following:

• Repository: The server where a project’s collected files are stored, as well as the source code management system used to track code changes. Developers “check out” code files to make changes, then save them back to the repository when their development work on that code is completed. The source code management system saves a new version of the file without replacing the old one.
• Check out: The act of taking a file from the repository to work on, which automatically locks the file so no other developer can update it.
• Check in: Refers to saving the checked-out file back to the repository once changes have been completed, which removes the lock.
• Commit: Another word for “check in.”
• Trunk: The main development line of a file tree under version control.
• Branch: A copy of code created off a project’s trunk. Branching allows multiple copies of the same file to be worked on in different ways, independently of each other.
• Merge: The integration of two sets of changes into a single file, such as joining a branch back to the trunk or joining two branches together. There are numerous merge strategies to consider; one such strategy is rebase, which allows you to rewrite commits from one branch into another.
  

Source code management vs. version control

Version control is a revision control system designed to track changes to code over time. The term is often used interchangeably with source code management.

Version control is managed with version control software that tracks every code change in a special type of database. When developers save changes made to a file, the system retains — rather than overwrites — all the changes from every previous version of that file.

Maintaining a versioned record of all code changes in this way offers several benefits, as we'll see below. As part of the branch strategy, there are two types of version control systems: centralized and distributed. 

• Centralized version control systems maintain one copy of a project on a centralized server to which all code changes are committed. Developers can check out the specific files they need to work on, but never have a full copy of the project locally.
• Distributed version control systems allow developers to clone the repository to their own local server or machine so they have the complete history of the project. Devs then clone the code they need to work on from this local copy of the master repository. When they’re done with their changes, they commit them to their local source code repository, then “push” this local repository code to the master repository.

Each type of version control system has advantages and disadvantages. Centralized version control is simpler to set up, less complex and easier to learn than distributed version control. It’s also easier to control access because code is stored on a single server.

Performance is generally faster in distributed version control systems because you don’t have to be connected to the network, which potentially slows connections. You also don’t have to wait for locks to clear to access the code because the complete codebase is already on your local system. And if the main server goes down in a distributed version control system, you still have the complete code history saved and stored locally to serve as a backup.

Version control in DevOps

Source code management plays a pivotal role in the DevOps lifecycle. Many modern source code systems now include CI/CD capabilities such as Github actions, Gitlab pipelines and Microsoft's Azure DevOps server. 

The DevOps lifecycle consists of seven phases that bring structure and continuity to software development projects. Here’s a closer look at each.

• Continuous development. Planning and software coding consumes the first phase of the DevOps lifecycle. Developers establish a project vision and initially develop and maintain the application source code.
• Continuous integration. In this phase, developers continue to modify the source code, changing on a daily or weekly basis, and new code is written and integrated into the main codebase to bring new functionality to the application. Bugs may also be detected in this phase, as developers perform unit testing, code review, integration testing, compilation and packaging of the code they’ve written.
• Continuous testing. Developers send their code to testers to check the application’s performance and test it for bugs. The information produced by these tests is sent back to the developers so they can make the necessary code changes to fix any bugs and optimize the application’s performance.
• Continuous monitoring. In this phase, developers monitor the performance and reliability of the application and its infrastructure. This helps them determine the availability of the app’s services, diagnose root causes of system errors, and identify and resolve any security issues.
• Continuous feedback. Customer feedback is gathered to evaluate the application’s user experience, which is collected by either structured feedback such as questionnaires, surveys, and focus groups, as well as unstructured feedback, which is gathered from social media platforms such as Facebook and Twitter. Developers use customer feedback to evaluate the current app and make changes based on user response.
• Continuous deployment. Developers deploy the final application code to production servers to make it available to users. (Note: deployment is not always the same thing as a release.)
  
• Continuous operations. In the last phase, the process of releasing the application and its updates are automated to accelerate time-to-market.

---

---

Benefits of source code management

Source code management offers many benefits, including:

Complete version history

The source code management system will maintain a running history of every saved code change, allowing you to see all changes in a file as well as who made the change and why over the project’s lifetime. The same record enables you to roll back code changes to a previous version if necessary.

More effective collaboration

Teams of developers can work on different areas of a piece of code in their own workspace without fear of overwriting each other’s edits. The system alerts developers to conflicts introduced by isolated code changes, which they can review and address before errors are introduced into the merged code.

Workflow automation

For source code management to be effective, developers have to follow a prescribed workflow. Some source code management tools can automate requirements, such as:

• Turning comments on.
• Sending an email notification when a particular step is completed .
• Notifying management when an expected step did not occur.

Better communication

Source code management typically includes the ability to comment on particular code changes in its workflow, fostering more communication within development teams, management, users and especially geographically distributed teams.

Graphic displays of code history

This feature of some source management tools presents code history as a diagram, making it easier to see code branches, merges and releases.

Generated release notes

The source code management system can link code to a release and generate release notes, saving the time otherwise required to search for changes and generate notes manually.

Code backup

Source code management provides a centralized location for developers to store their code to ensure everyone has access. This arrangement also makes it far easier to back up code than if each developer stored their code on their personal machines. 

Pipeline analytics

Proper source code management augments the value you can achieve through pipeline analytics. Tracking application-level and infrastructure-level metrics provide deep visibility into application environments, allowing teams to identify and address performance issues within applications or infrastructure.

Source code management systems

A source code management system is a software tool that coordinate a software development team’s coding work. As described earlier, these tools might also be called version control systems or source control systems.

The main function of a source code management system is to provide file and configuration management and version control capabilities in order to

• Ensure development teams are always working with the latest code. 
• Prevent devs from overwriting each other’s code changes. 
• Work on code in parallel and merge changes . 
• Track and review requested changes, monitor bug fixes and perform releases.

There are many available source code management tools and systems on the market. The type and number of features best for you will depend entirely on your organization’s size, resources and needs. Popular tools here include Bitbucket, IBM Rational Clearcase and open source tools such as Github and Apache Subversion.

Best Practices for Source Code Management

To get the most out of source code management, it’s important to follow a few best practices:

• Commit often. Every commit is a snapshot of the codebase at a particular point in time. Frequent commits allow you to incrementally save completed changes to the codebase, which gives you more opportunities to revert to an earlier state if a change results in an error.
• Include a commit message. A commit message communicates the context of a change to other developers, and is often helpful for troubleshooting should problems arise from particular changes. Development teams have different conventions for writing commit messages, but generally they include a short line of text specifying the type of commit (e.g., new feature, bug fix, refactoring) and more detailed body text explaining what changes were made and why. For pipeline analytics, the commits should include backlog ticket numbers. 
• Work on the current version. With multiple developers making rapid code updates, your local copy of the codebase can easily fall behind the master copy. Check out the latest codebase before making changes so you’re working with the most up-to-date version. Moreover, versioning for microservices and CI/CD pipelines can be very different. 
• Standardize team workflows. Every developer has their own preferred processes on projects. But for SCM tools and procedures to be effective, development teams need to establish consistent workflows which creates the foundation for a better product.
• Use branches. Branches create separate lines of development to allow developers to work in parallel on the same codebase without impacting each other’s work. They should be used frequently and adhere to defined branch practices and strategies (creating a new branch for every change, for example) to ease integration into the main development line.
  

Source code management is essential for modern software development

As projects and the size of their respective codebases grow in number and complexity, source code management is becoming a crucial tool for software development teams. Modifying the wrong version of an app — or worse, releasing it with bugs you were supposed to fix — carries heavy costs in the form of lost time, money and customer loyalty.

Source code management is easy to implement, and when done effectively, can accelerate your development process, increase team productivity and improve the quality of your product.

What is Splunk?

This posting does not necessarily represent Splunk's position, strategies or opinion.