Promotion Levels
Return to Introduction  Previous page  Next page
A Promotional Model is a definition of the steps that a project or group of files need to go through to be considered ready for production.

When developing software, particularly when multiple projects/versions are involved, it can be quite difficult to define which stage a particular release of a product is at. In particular, when many people are involved, the whole exercise can be quite daunting. Using a combination of Promotion Levels and Views, it is possible to control this process and simplify the development/testing of any project.

Put simply, Promotion Levels define the stages that your software goes through before it can be released to the public. A typical example would be:

·Development – developers work on the software  
·Testing – The software goes through initial testing  
·QA – the software goes through the QA process  
·Production – The software is considered safe to be released  

In Team Coherence, there is no need for the Development level as this is defined in the default <default> View.

Obviously, developers are not going to stop development of the software while it is tested. Similarly, the QA process can't start until the Testing process is completed. Without a promotional model, this process can cause bottlenecks and confusion.

This kind of scenario can be handled using Version Labels, but there is huge scope for error since there is no simple method of guaranteeing that a particular department is working with the correct version of the software, especially since the development process is continuing.

Defining Promotion Levels allows you to define, independently of the main development stream, how your project progresses through the various stages. In a simple scenario, if we take the above stages:

promotiondiag  
Developers would work using the default view. When happy with the files they are working on, they would assign a Version Label to the files and promote the files to the first stage, Testing, and carry on working.

Testers would select a View based on the Testing promotion level, and test the software. Any bugs found would be reported to the developers who would fix the problem and re-promote the fixes to the Testing level. Once the testers were happy with the results of their tests, they would promote the files at the Testing level to the QA level.

QA would then run their tests on the project and if problems occur the files will be fixed in the <default> level and re-promoted. When happy, QA would promote the final product to Production.

Since Views based on Promotion Levels are read-only, the only way fixes can be applied to any promotion level is to go back to the initial stage and re-promote the problem files through the various stages again.

This ensures that, at the final promotion level, all files have progressed through all the defined stages in development.

 


© 1995-2018 MCN Software