Application Security Testing: An Integral Part of DevOps
Microsoft entered the source code control business with Visual SourceSafe back in the 1990s, and even today, the product continues to be used by a large number of development shops. Still, many organizations have noticed SourceSafe to be problematic: database corruption is common. Since development companies live or die by their source code, one must be able to trust the software managing it.
When Microsoft chose to implement a replacement for Visual SourceSafe, the company had several goals in mind. These included speed, robustness and support for higher loads. This development lead to the version control system that is today part of Team Foundation Server (TFS).
The architecture of TFS is centralized. This means that all source code is maintained at a single location. In a centralized architecture the TFS server itself can be considered a single point of failure, but with high-availability solutions available in the Windows Server operating system, this does not need to be so. Similarly, the SQL Server database storing the actual source code bits can be mirrored on multiple servers.
This article will explore the source code control functionality in TFS 2010 (Figure 1). Although the focus is on the latest version, you can still benefit from this article should you be using for instance the 2008 version. Some of the details might not apply to version 2008, but the basics are still the same.
Figure 1. Team Foundation Server version control is integrated into Microsoft Visual Studio and Expression Blend.
This article assumes you are familiar with the basic operations of TFS. If not, be sure to read the first part of this article series about Team Foundation Server and Microsoft's ALM solution.
Version Control Support in Team Foundation Server (TFS) 2010
Dependability and robustness are key ingredients to a professional version control system, and this is what TFS 2010 aims to deliver. In fact, version control can be considered core functionality in Team Foundation Server. Other features, such as team builds, are built to benefit from it.
TFS version control has been designed to integrate seamlessly with the latest versions of Microsoft Visual Studio. However, this does not mean that you could not use TFS version control with other software development products. It is also possible to use the version control fully manually through a command-line utility called tf or in a somewhat more limited fashion through the web access feature of TFS (Figure 2).
Figure 2. The TF command can be used to manipulate item in version control from the command-line.
- The functionality in TFS can be divided into the following areas:
- Basic functionality: checking files in and out
- Locking: limiting concurrent edits
- Branching and merging: work with different versions of the source code
- Security: decide who can access the version control data and how.
The basic functionality in any version control system includes checking file in and out. To support concurrency, TFS allows multiple checkouts of the same file, but this can be disabled should the need arise. Items can also be exclusively locked so that nobody else can check in or out a file while it is locked. If concurrent checkouts are disabled in team project settings, then a lock is automatically placed on the file upon checkout.
Branching and merging can be considered advanced functions in TFS, but nonetheless, they are highly useful. The main idea of branching is to take a set of source code files and create a distinct version from those files. The branched code can live a life of its own separate from the original source files (Figure 3). For instance, if you are developing a generic application but need to make a specialized version for a certain customer, you could branch the customer customizations from the main source control tree (the "trunk"). Should the need arise later, you can again combine the customization code with the original source control line. This is called merging.
Figure 3. Branching and merging are useful functions in larger projects with continuous development.
Everything in TFS except Active Directory user rights version control are stored in a central SQL Server database. This includes team project settings, file data, changeset details, and so on. Because almost everything is in a central location, it is imperative to make sure you take regular backups of the SQL database(s) and have a disaster recovery plan. TFS backups can be taken with regular SQL Server backup tools, such as the built-in commands or with third-party products from names like Symantec or CA.