- Promotion Path: Supports multiple connected environments such as DV, QA, TR(Training, mostly optional) and PD. This allows you to checkout a source from PD to DV, and then promote it to QA and then to PD. Separate environments allow you to work on one environment, letting business users test in QA, and end users use the PD site, each not disturbing each other. The promotion of sources through the promotion path is automatically handled by SCM in the EEM application with built-in tools.
- Projects: Projects can be made mandatory as part of SCM. Multiple sources can be contained in a single project. Projects are shared across multiple developers. Sources inside one project are always promoted or demoted together.
- Revisions: Every promotion to PD is controlled using revision. Each time a project is promoted to PD, SCM will snapshot all the sources that were promoted as part of that project. The promoted sources before and after the promotion are seen as revision and are a collection of sources. A developer is able retrieve a source from an older revision or compare changes between an old and current revision.
- Application Versions: Just like EASYProcess or Web browsers, the application you create with EASYProcess can have a version. Since developers have control over changes made to sources and are able to promote them through the promotion path and make new revisions, the developer is given control over when new versions start and end. A decision could be made that after this year, the application will move from Build 1 to Build 2. At this time, the revisions should restart at 1. SCM gives the ability to restart the revision number and control the version and build numbers of the application. The format is: [MajorVersion].[MinorVersion].[Build].[Revision].
Environments in Promotion Path
DV, QA and PD are not the only environments that can be set up in the promotion path. The environments can be set up according to the clients needs. Each level of the promotion path after the DV environment would be further from development and look more like the production environment as far as specs and data. The testing in each level might also differ. Below are some examples of additional environments and possible needs for them.
Multiple Testing Environments: There can be several levels of testing environments. Some examples of different testing are System Integration Testing (SIT) and User Acceptance Testing (UAT). SIT tests the integration of a new feature/fix with the existing system in place. UAT testing simulates actual user behavior. The testers of this environment might not be aware of how the feature works and would be an accurate simulation of actual users.
Training Environment: This would allow new users to be trained on the system without affecting any production data.
Pre-Production Environment: This would be maintained as a copy of PD. These are usually given the same specs as the production server so that stress tests can be performed.
Our SCM compiles all changes into projects. So if the change requested (issue fix or feature) requires multiple webparts or processes, those can be grouped into projects and moved through the promotion path together. This ensures that a feature will not be unstable for the few minutes it takes the developer to promote all the associated webparts and processes.
An unstable feature could result if half the feature was promoted at 12:00 and the other half was promoted at 12:30. Any testers using the site during that time would receive unexpected behavior. Projects protect against this by giving the developer the option to promote projects instead of the individual sources that compose them.
Each state of PD is assigned a revision number. The revision number is an auto incremented number assigned to the state of PD after each promotion. New revisions are created when a project is promoted to PD. SCM allows these states to be saved and accessed. The sources of older revisions can be compared to the current revision or PD can be reverted back to a previous state.
It is sometimes useful to view the source of a past state of production. For example, after a promotion, if a new issue arises, the last revision can be rolled back to the last stable state while developers can look for the source of the issue in a non-production environment.
With many revisions, it would be easy for all the changes to get disorganized. The Application version is a tool that can help keep revisions separated in a meaningful way. For example, after a certain project is moved to production, it could be decided that the application has entered a new phase. This phase could be marked with a new build number and restart the revision count. The application version could go from 126.96.36.1991 to 188.8.131.52 through the application version tool. The format is:
This is controlled from the end environment in the promotion path. In that application’s configuration variables, there is a configuration called “Version”. Here all aspects of the version number can be edited. The Version and Builds will need to be manually incremented as the application evolves and it is determined to have entered a new stage. The revision number will be automatically incremented as projects are promoted through the promotion path. It will then look to find the current revision number as defined in the Version configuration, add 1, and update the value to be the new revision.
This value can be found in EASYProcess in the “About EASYProcess” section under “Help”.