Veteran and novice developers alike need source control management (SCM). Also known as asset management, and source code management, SCM helps you (and your team) manage development projects, and the components and code that make up the project.
There are many benefits to using source control management, most notably the ability to develop code faster, smarter and more accurately. Source control management tools help you control your code; especially in multiple developer projects.
For the purposes of this article we will be referencing Evolution personal edition – a free source control software robust enough for beginning and veteran developers alike. It might be helpful to actually have a source control solution at hand as you read this article – giving you a real life reference to the concepts described below. You can download Evolution personal edition for free here.
If you have a question about the concepts in this article – you can post them to our forum.
In this article, we are going to discuss the following source control management concepts.
- Promotion Ladders
- Evolution Branches
Permissions vary from tool to tool – but typically they are user/group based. Many of you will find this familiar to the Windows OS style of handling security. If you are using Evolution, your objects can have permissions applied to them. This is important if you are working with several developers, and want to control who has access to what files, objects, and components.
Permission rights can also be granted or denied as you promote code (code promotion is discussed below in Promotion Ladders). So a Quality Assurance (QA) Manager user can be granted access to the Quality Assurance promotion stage for a particular project. Now only they have the rights to promote into the Quality Assurance stage.
In many development teams, there is usually a group that develops a component of the overall project and releases versions to the rest of team incrementally. Evolution handles this by using promotion ladders.
A promotion ladder outlines the stages through which code flows. It is completely customizable so development teams can configure separate ladders or use only a single organization-wide ladder. For example, “Live,” “Test,” and “Acceptance” would be the steps of a simple ladder. Developers can move their code ‘up the ladder’ as it is tested and proven. The development team now knows exactly what code is where in a process, with complete reproducibility.
Promotion ladders also allow particular components to be marked, so that multiple projects can use the same component and include the correct version of code in their project. The “Live” overall project should only ever contain other sub-projects that are also at the “Live.” In other words, the live overall project is composed of smaller pieces (or components) of tested and approved code.
**Do you have a question about Source Control? You can contact the Evolution Development Team: [email protected]
Event triggers are used to implement the actions, automatically, as your project grows up the promotional ladder. By settings triggers on system events, for instance when code is promoted to ‘Test’, operations can be automatically carried out.
Code moves upwards through your ladder. For example, let’s work with three promotion levels – Development, Staging, and Test. When a developer promotes their project to the ‘Staging’ step, an email is sent to the Quality Assurance Manager. Using a Staging level between Development and Quality Assurance is important, because you are ensuring that the QA team’s test environment will not be polluted without their knowledge. Rather you allow the QA manager to promote code from Staging to Test when the QA Manager deems his team ready to begin testing the new code. When the QA manager promotes code from Staging to Test, the QA group is automatically notified via email that there is new code to be tested.
Teams can implement as many or as few level of control as they want.
Productions are a proprietary feature of Evolution. At the simplest level, a Production is a basic grouping of files. With Productions you can easily control a group of files simultaneously. A key feature of a Production is the ability to create a snapshot of the Production at any point in time. A version of a Production refers to specific versions of the files contained in it, as well as exact versions of other Productions.
Productions are powerful because they eliminate haphazard code changes, whose composition is determined only by time of submission. The Evolution Version Manager allows you to specify what versions of what objects compose the version of the Production being created. Instead of managing thousands of changes set individually, a project leader can create snapshots of larger components as needed.
Evolution has several branch types at your disposal with which to implement your development process. Implementing branch types takes place outside of the promotion process, the development process is the means by which code is produced for promotion. The promotion process is the means by which code is approved.
Shares: Evolution objects can appear in any number of views. A single object (file or Production) can be referred to by many projects or Productions (discussed below), or none, in which case it is considered orphaned. When an object is removed from a project or Production, it is simply being unlinked from it, but it still exists in the system.
Clones: A clones is an exact replica of an object. Data replication occurs at creation time, at which point the object becomes completely separate from its archetype object.
Shards: A shard is an exact replica of an object without data replication. When either shard is altered, the become clones, at which point data replication occurs. Sometimes this is called a “branch on change.”
Reflections: A reflection is a unidirectionally managed copy. When an object is reflected, it becomes the archetype to the reflection. So when you make a change to the original file, the reflection is changed as well. But changes to the reflection do not effect the original file. This is recommended for OEM of maintenance release codelines.
By using any or all of these branch types, you can create simple or complicated workflows. You can refer to the Evolution User’s Guide for complete documentation of branch types.
Putting It All Together
Let’s say a project is ready to begin. We will briefly walk through the main points of interest in a sample process.
- A project begins and a department manager promotes the project Production into the Development stage.
- An automatic email notification is sent to the Development Team.
- The members of the Development Team create private workspaces (shards) of the main project (let’s call it Project X).
- As each team member is ready, they harmonize their workspace with the main archetype [Project X] Production.
- The Development Team produces code that is ready for testing and promotes [Project X] version 17 into the Approval stage.
- The Evolution server denies this action because only the QA Group has the rights to promote into Approval.
- The Development Team learns its lesson and properly promotes into the Staging step.
- An automatic email notification is sent to the QA Manager, who immediately promotes [Project X] version 17 into the Quality Assurance stage since his team is ready.
- [Project X] version 17 is automatically pushed to the test server for the QA Group to begin testing upon receipt of the automatically sent email notification.
- The QA team finds bugs and bounces [Project X] version 17 back to the Development Team.
- Steps 2 through 7 are repeated, but with [Project X] version 20 instead of 17.
- QA finds no critical bugs and promotes [Project X] version 20 into the Approval stage.
- Project Lead receives the automatically sent email notification and promotes the fully tested code into the Live stage.
- [Project X] version 20 is pushed out into the live environment.
As you can see, the iterative process of getting code, or sending emails to inform teammates of events is taken over by Evolution completely. The Evolution system also enforces a rigid release cycle while still giving developers the freedom to work within their development process of choice without being encumbered by the requirements of the release cycle.