Best Practices for NWDI: Track design for ongoing development
This paper contains recommendations for track design for NWDI-based development. It describes a track design for ongoing development where the release cycle is very short. Development groups need to develop applications that are shipped or deployed to a production system within a short software life cycle. This means ongoing developments and improvements to shipped software are performed in parallel, and the new changes are shipped in a short time frame, e.g. once a week. In this situation, the release cycle is very short and the shipment or deployment to production systems is done immediately after test and approval. The released software is not a new version or release; it is, more or less, a continuous improvement of existing functionality. This article assumes familiarity with the NWDI, especially how to set up and maintain tracks and runtime systems within the CMS WebUI.
Limitations in a Single Track Landscape
In most cases, a single track is sufficient for this scenario. During development of the next version in DEV, the CONS system is used for urgent bug fixes to the released version that is deployed in the production system. As soon as the new version is imported into the CONS system, there is no longer any chance to fix bugs in the current production version. The reason for this is that the track template does not include workspaces and buildspaces for TEST and PROD systems. If a bug occurs in the production system, the only way to fix it is in the CONS system and to ship it together with the new version to the PROD system.
Maintenance Track Approach
The requirement to fix bugs at any time cannot be fulfilled within a single track because there are time frames where the CONS system is blocked with the new version. But the new version is not ready for deployment to the PROD system. This means you require a second track, which is usually called a maintenance track. The maintenance scenario is described in the weblog Best Practices for Running the NWDI). Usually bugs are fixed within the Maintenance track and there within the DEV development configuration. With a repair connection the fixed bug is automatically progagated after the developer releases his changes to the Development track into the import queue of the DEV system. This feature is designed to avoid double maintenance and to make sure that all fixed bugs are automatically integrated into further developments.
Usually the scenario described here for creating a maintenance track for the shipped release is our recommended scenario. Here, the software component is deployed to the production runtime system after it has been transported through the maintenance track. There is no PROD runtime system in the development track. But in some cases, as in the case described above where the release cycle is very short, the transport through a maintenance track is too much overhead and takes too long. In a maintenance track, where buildspaces and workspaces are created to be able to maintain a release, the software is of course built again in DEV and CONS, and must be assembled again. It is obvious that this is overhead for the scenario described above, where bugs are normally fixed in the CONS system of the development track. One way to speed up the deployment process would be the following scenario, where the PROD runtime system is added to the development track to deploy the new changes immediately after the approval step. The same PROD runtime system is also added to the maintenance track. Only in the rare case where a bug cannot be fixed in the CONS system of the development track, must the version deployed to production be imported into the maintenance track in order to fix the bug. In this case, the fixed version of the software component is assembled in the maintenance track and deployed to the common PROD runtime system. In all other cases, the maintenance track is not used. In general, this scenario is not recommended because it can lead to situations where older versions overwrite new versions during deployment, as described in the following example.
Version 1.0 is developed in the development track and shipped/deployed to the production runtime system. There is a track connection of type Transport between the development track and the maintenance track. This means Version 1.0 is propagated to the import queue of the DEV system in the maintenance track. In the meantime, the development of Version 1.1 is ongoing in the development track. An error occurs in the PROD system in Version 1.0. This bug can now be fixed in the maintenance track. After the bug is fixed and tested it is transported through the configured PROD system (in the maintenance track) to the PROD runtime system. In this case, everything is fine and the production runtime system now contains Version 1.0 BF1 (Version 1.0 including bug fix 1), which hopefully solved the problem. Now, the new version 1.1 is ready and deployed to the production system (using the PROD system of the development track). Again, an error occurs in the production version 1.1 in the production runtime system. The bug must be fixed in the maintenance track, because V1.2 is already deployed to the TEST system in the development track. Here, a problem can occur when the administrator forgets to import Version 1.1 into the DEV system of the maintenance track. Therefore, it could happen that the developer fixes the bug in an older version which is then deployed to the production runtime system. In our example, Version 1.0 BF2 (Version 1.0 including the bug fix 2) overwrites Version 1.1.
If a runtime system is attached to multiple tracks this may lead to the problem that an older version overwrites a newer version already deployed in the production runtime system. The following deployment sequence is possible: 1) Version 1.0 2) Version 1.0 including bug fix 1 3) Version 1.1 4) Version 1.0 including bug fix 2 Neither the deployment tool SDM, which is triggered using CMS, checks the versions, nor is this done by CMS itself. CMS can only handle the version sequence properly if a runtime system is attached to exactly one system of a track.
Recommended Track Design for Ongoing Development
One way of avoiding that an old bug/version comes back again and again is to make sure that the import queue of the DEV system of the maintenance track is empty. Every time a bug has to be fixed, the entries in the import queue must be imported successfully before the developer starts to fix the bug. This is an organizational and process-driven solution; there is no tool support. A better way to solve this issue (and our recommended solution) is as follows: CMS can check the versions to avoid such a scenario. But this means the track design looks a little different. The following track design describes a way of handling the rapid deployment of new changes and immediate fixes to bugs. But this case is very rare, so there is no general requirement to transport source code through the maintenance track every time new changes are deployed. The proposed solution is based on the maintenance pattern, but the development and maintenance tracks have no configured PROD systems. This means there is no direct deployment into the PROD runtime system. The deployment to the PROD runtime system is performed using a separate PROD track, as shown in the next image.
The PROD track only consists of the runtime system PROD. There are no DTR workspaces and buildspaces configured in this track. How to setup such a track is described in the NWDI documentation. Track connections are used to propagate the approved versions of the software from the development track, as well as from the maintenance track to the import queue of the PROD system of the PROD track. Within the PROD track configuration the software component is added as required software component. The advantage in this scenario is that CMS does not allow the deployment of an older version when a newer version is already deployed. This is possible because CMS can compare versions within one import queue even if they are assembled in different tracks. So, the overwriting issue is solved. Please keep in mind that the standard maintenance scenario is still valid here. Which means, the import queue of the DEV system in the Maintenance track has to be empty before a bug can be fixed. And the back transport is used to integrate the fixed bug. There the entries in the import queue of the DEV system in the Development track has to be imported as well, before a new version is going to be approved. For the example described above in this scenario, the CMS checks the versions before deployment and you not at risk of overwriting newer versions. The following sequence is therefore no longer possible: 1) Version 1.0 2) Version 1.0 including bug fix 1 (OK) 3) Version 1.1 (ok) 4) Version 1.0 including bug fix 2 (is blocked) For the ongoing development scenario, the recommended track design combines the advantages of a single track (fast life cycle) with the advantages of a maintenance track (bug fixes at any time), while reducing the overhead of a typical maintenance landscape.