CA defines a Life Cycle as:
…the set of all the stages (states) a change or release goes through from identification to completion; it defines a model for a particular development and maintenance process.
Anyone who’s been with this product for a long time will inevitably chuckle to hear the term Life Cycle because it’s the third name for this feature. The evolution is Environment–>Project–>Life Cycle. In the database, you can still see the evolutionary evidence of Environment in the table name HARENVIRONMENT. You can also see the evidence of the product’s former name: Harvest. 🙂
Regardless of what you call it, it’s a damn good thing. This is what differentiates CA SCM from a version control system. It is a Software Change Management system. You cannot change source without a Package (CA SCM’s representation of a software change unit of work or project task), and you cannot have a Package without a Life Cycle. It’s up to you just how much accountability and control you want for you Life Cycle, but this is a tool that really wants you to operate in a well-defined, well-documented, repeatable process.
You can start from scratch or you can use another Life Cycle as a template. For the sake of repeatability, I chose to use an existing Life Cycle as a template. CA SCM comes with a library of very useful templates from which to choose. I chose the Release Model for this particular software release.
It has four States: Development, Test, Release, and View SnapShots. Each state has a list of pre-built processes. Also, notice that it has a set of Data Views. A view is how you isolate change in states. For example, the Test view shows the state of the code in the Test State. You will not see code that’s still in the Development State in the Test View.
To make this template an Active Life Cycle:
- Select “Copy To …” from the context menu for the template
- Name the new Life Cycle. You should give it the name of the software release you are about to begin.
- Click OK!
By default, rights and access within this Life Cycle are controlled by two User Roles: Dev Manager and Developer. You must assign team members one of these roles for them to be able to use this Life Cycle. You can also choose to create your own User Roles for more fine grained and project-specific control.
So, we have a life cycle. These out-of-the-box templates are very well-documented, in the Administrator Guide, so I won’t go into the details. But I will say that this is a fairly sophisticated release management process that can be extended to become a full-blown continuous integration environment. So what’s next? Remember our important CM word for CM studs only? Yes, that’s right, it’s time for a Baseline…