With this post, the Communitech Apps Factory kicks off its DevOps blog series, aimed at helping startups develop their products faster and more efficiently.

Our suggestions will lean towards lightweight tooling and processes, and will hopefully add value to your team’s development efforts.

We'll start with a look at Version Control Systems (VCS) and the steps needed to implement them effectively. We’ll also offer an analysis of different systems and the opportunities they offer.

While this piece focuses on Git, and how we use Git in the Apps Factory, we encourage you to look critically at all the options, given the importance of VCS to your development team.

Holistic Perspective

Before we outline the steps to determining which VCS (or any system for that matter) is appropriate for you, there are two fundamental perspectives that need to be considered:

• External: What type of software is your team building? What kind of release schedule will best meet the needs of your stakeholders and clients? Who are your stakeholders and what do they prefer?

• Internal: What is the chemistry of your team? Are you developing one product at a time, or multiple products? Is everyone involved in the review and approval process? Do you need centralized decision-making? Are all your team members in one location, or are they distributed across several sites?

While these things might seem obvious, teams often choose development processes based purely on technical merit (“This is the industry way of doing it”) without considering the implications for their clients, such as the delays those processes might cause.

Building great software is like building a house: If there are inconsistencies in the materials or the design, you will have a weak foundation, and as you keep building, the house will crumble for lack of a solid base. Too often, teams implement systems inconsistently and end up struggling with scale and growth issues downstream.

That’s why VCS is so critical: It helps shape the decisions your team will need to make in other key areas, such as:

• approaches to code review and appropriate testing systems

• appropriateness of continuous integration systems

• project management systems like issue-tracking, backlog and team management

• branching strategies

We can view all these systems as pieces of a puzzle and how “well” they fit is determined by the external (business) environment.

So what is VCS? Which do I choose?

A VCS is a concept that adheres to a view that all changes to a code structure can be represented by revisions. A VCS organizes and keeps track of these revisions in a logical way, and is a simple yet powerful tool for a team to manage multi-developer projects.

While it’s easy to pick one form of VCS, a common industry practice is to integrate many systems based on the business environment and the constraints teams face. This goes back to the analogy of viewing VCS as a puzzle.

The rest of this article will look at the steps your team can take to implement a VCS.

1. Choose a VCS

Going back to the house-building concept, it is important to select a VCS that fits your team’s opportunities as well as its constraints. The following diagram will help differentiate between the many version control systems available:



Some notes:

• High External Stability/Low Internal Stability: This environment is characterized by waterfall management where project timelines are long and rate of change is low, as in the banking and insurance industries. Normally, centralized VCSs such as SVN, Perforce and ClearCase will suffice. The focus here is on enterprise-by-design, so concepts such as security, stable release and branch structures is key.

• Low External Stability/Low Internal Stability: The focus here is on rapid development, and the need for “agile” methods is paramount. The startup, open-source and prototype-development fields are characteristic of this segment of the industry. Distributed systems such as Mercurial(Hg), Git, CVS and to a certain extent SVN, are ideal. These systems are characterized by short branch life and lack of approval mechanisms.

• Low External Stability/High Internal Stability: Usually characterized by organizations in transition. Where product lifecycles are under pressure to be shortened, systems that offer some cross-platform support yet maintain security and stability are ideal. Industry tends to point towards Perforce and SVN.

• High External Stability/High Internal Stability: Similar to the first case, stable and prescriptive methods are ideal given the length of project cycles. Systems such as ClearCase are ideal.

In the context of the Apps Factory, Git is the ideal candidate given the following scenario:

• prototype development

• distributed in nature

• rotation of development resources is quite high

2. What goes in?

What goes into a VCS depends largely on the concept of maintainability. Naturally, your software project should be the first thing that comes to mind (else, it defeats the purpose!). But what else? If a team tends to wiki/document meetings and processes, a system to maintain versions is often ideal; the phrase “A process is outdated once it’s put on paper” comes to mind. Depending on how collaborative your team is, a VCS might be appropriate. Solutions such as Confluence offer their own revision systems.

3. Structuring your system

Different VCSs have their own “best practices” for structuring their files, depending on how the systems are implemented. How and where you submit your revisions can vary, but an underlying theme of any VCS is the concept of a “main line” of development. This is where the key words “centralized” and “distributed” separate the various systems:

• Centralized: VCSs such as Perforce and ClearCase advocate the main line of development to be the central meeting place for developers with the onus on a single, central repository. Any changes or revisions need to go here before your product gets shipped.

• Distributed: As the name implies, VCSs in this category tend to be flexible systems where the concept of a single “master” branch, and a single repository for revisions, is unheard of in a multi-developer environment. Branching, which is an abstract way of structuring revisions, will be discussed in a future post.

4. Agree on conventions

VCSs, by design, are meant to support abstraction of code structure so that there is always flexibility in how you use a system. At this point, it is important to agree on conventions to ensure your team utilizes the benefits of a VCS. Topics that should be discussed include:

• How regularly should developers update their code? By not updating regularly, you end up working with old versions of code, which increases merge/integration conflicts down the road.

• How big should the revisions be? The more dependencies the revision contains or requires, the higher the risk of conflicts downstream.

• Commenting. Useful comments don’t just benefit other developers (by helping them understand what the functionality is), but are also helpful when looking back at a project’s history. Stress useful comments over ones (as I plead guilty to making) such as, “Fixed a bug.”

Fit with next topic

Now that you have a better understanding of what a VCS is and the steps to selecting and deploying one, we’ll briefly introduce testing and code review in a startup environment.

While there are many ways to test and to perform code review, the selection of a VCS will have an impact on the tooling you will need for adequate testing processes and code review systems.

Our next DevOps blog post will look at Git-friendly tools such as GitHub, Gerrit, and ReviewBoard. We'll also look at code review approaches such as peer programming!