The purpose of this installment is to clarify the lines between the different types of management when it comes to software projects. Before moving on to the more complicated aspects of source control, it’s worthwhile to spend a little time discussing this.

As I mentioned in Part I, source control has an awful lot of names. The reason for this is that it can play so many roles in your development process.

At ionForge, we still like the term “source control” because it’s what we’re used to and it’s easy to understand. If you tell someone that you make “software configuration management” tools, you generally get a very blank stare back. So in general that’s how I refer to things in the same class of application as Evolution.

Digital Asset Management

Every source control system needs a solid core revision management system. A central repository where data is stored, along with the ability to get and submit data is a fundamental function of source control, and every system does this for you.

Managing server storage space, handling binary files, ensuring repository integrity, and providing functionality like atomic transactions (described in Part III) are all within the realm of asset management.

Source control is traditionally limited to these functions. While this is the foundation on which everything else is built, as software development teams’ needs have grown, so has the overall role of source control.

Workflow Management

While asset management handles the actual components that comprise your projects, workflow is the way in which you manipulate them. Even though your source control system manages your files, you need to use those assets to collaborate with the rest of your team.

How you interact with the assets managed by source control, and how that impacts your team, is workflow management.

Products such as Microsoft( Visual SourceSafe are primarily asset management systems with little in the way of workflow. Often development teams build workflow systems around asset management systems, but more modern source control tools provide this type of functionality natively.

You may have heard of the term “branching” as it relates to source control. Branching is taking a single object and making it two or more things. Different source control systems give you different ways to synchronize (or “harmonize” as we refer to it in Evolution) the resulting objects.

One reason to branch is to maintain several distributions of the same application. Another reason to branch is to create private workspaces, described in Part III. By branching entire projects, developers can work together and merge their changes when they are ready.

Branching will be explained in detail in the next paper.

Promotion Management

We previously defined 2 primary purposes of source control: Revision tracking and collaboration. Digital Asset Management gives you revision tracking, and workflow management corresponds to collaboration.

Up until this point, we have talked about things that are primarily of concern to the developers. With promotion management, we are bringing the rest of the team into the loop.

Source control systems that provide promotion management, like Evolution, allow you to create triggers on events that can fire notifications to the appropriate team members, deploy assets to test or live environments, kick off build processes, etc.

One mistake is to use branching to create promotion paths. Here is a very simplified process:

1. Development does their work.

2. Quality Assurance tests the work.
3. Management approves the work.

Notice the use of the word “work”. This is the term we will start using in future papers, because that’s what source control is ultimately about, making work faster, easier, more efficient.

By using branches to move work upwards through a process like the one above, you are introducing the possibility of change along your integration path. Quality Assurance isn’t assured that the work they are testing is actually the work that was performed by development. Management doesn’t necessarily know that they are approving the exact work that development did, not if it is the exact work that was tested by QA.

What you really want is to promote the exact work that was performed upwards through a promotion process.

Implementing a promotion process properly will be addressed in the next part.

Putting It All Together

When you start putting all of these together, you are creating a development pipeline. By understanding the differences between these concepts, while at the same time using a tool that provides all of them, you give yourself the flexibility to design a development process that works within the framework of your organization. This will streamline your team, saving precious time and manpower.

Future articles will begin to explore specifics in detail, and offer best practice advice for various common methodologies.

About the Author

Nick Ni is the Director of Technology of ionForge Company and the chief architect of the Evolution Source Control System. He has been a part of software teams of all sizes, developing products for consumers (such as PowerDesk, ZipMagic, and SystemSuite) to enterprise applications for financial institutions. He has led the development of Evolution from inception in 2001 to delivery in 2003 to the present time. He has been researching and implementing solutions for development lifecycle management for the last 5 years.

You can visit:
ionforge.com for more information about the Evolution Source Control System.
forums.ionforge.com to read more and ask questions.
blog.ionforge.com to get information directly from the Evolution Development Team.

(c)2005 ionForge Company. All rights reserved.