- 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 220.127.116.111 to 18.104.22.168 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”.
How SCM Works
SCM is a system that can be set up configuring the EASYProcess environments you wish to be a part of the promotion path. Each environment must be open during set up and changes will be made to each in order to link them together. SCM is entirely maintained by the configuration variables and records saved to specific SCM tables in the database.
The configuration variables define the relationship between environments and point to the servers they are on and the ports to connect to them. This is also used when promoting. The entities are auto-built in the next environment. This needs the IPs and ports to target the next environments for building.
Once linked via configuration variables in each environment, SCM is managed within EASYProcess Enterprise Manager (EEM). SCM is not its own application and can only be viewed through EEM. This EEM Application is responsible for maintaining each EASYProcess Application on the server and it can also allow you to manage its relationship with other EASYProcess Application environments through SCM. From here you can promote sources/projects, reassign to the available developers, or undo the checkout to return to the version from PD in every environment.
Each time a project or source is promoted, it is recorded in that environments database. This allows each environment to keep track of the sources currently existing in it. With PD at the end of the promotion path, PD’s records are more complete since it must know where all sources.
Below are the tables used:
EP_SCM_Projects: Stores projects
EP_SCM_Project_Entities: Stores the sources within the projects
EP_SCM_Revisions: Stores past revisions information (project, application version, created on/updated on dates
EP_SCM_Revision_Sources: Stores the sources within each revision
EntityCMSStatus: Stores the status of sources. The records from this table in PD is used to display the records in EEM and has much of the information displayed: EntityId (ProcessId/Webpage/WebpartId), Checked out by, Checked out on, Project. This also stores where in the promotion path the source exists in columns like CurrentLocation, LastLocation, NextLocation.
CMSDevelopers: Stores the available developers to work on projects