previous article
After dealing with the basics of a simple deployment process in the first part of this blog article, I would now like to address a few points which need to be considered with regard to WhereScape RED and deployment processes.
Development with WhereScape RED in a team
In general, development work usually begins with assignment of a specification ticket. It is advisable to minimize the specification's scope in terms of the WhereScape RED objects to be modified, because development in WhereScape RED makes use of a common object pool. In other words: The larger a specification's scope, the more likely that several developers will need to manipulate the same intersection of objects. Of course, there are ways and means of solving the problems arising as a result. However, this usually leads to dependencies in development, and ultimately to potentially invalid objects during deployment. WhereScape RED provides an easy and convenient way to ensure that even just a single developer will work on a particular object.
A check-out function (right-click on object) makes it possible to lock the object identifiably for all other developers, create a new version of that object, and set a locking period. At the same time, a reason for locking can be saved in the WhereScape repository. If a developer's work is discontinued unexpectedly and locked objects are left behind, it is also possible to force an unlock via the WhereScape repository.
Large development teams or extensive specifications, or an absence of appropriate development guidelines, make conflicts inevitable and cause invalid objects to impair the integrity of environments during deployment. It is therefore essential to establish suitable development guidelines, and test as well as check objects to be released.
Release in the context of WhereScape RED
A release comprises work results (artefacts) to be issued. In the area of data warehouses, an artefact can comprise a new version of an entire data warehouse or a single object, or a specific subset of a data warehouse.
It is advisable to use a delta procedure when rolling out WhereScape RED deployments. A release is then the sum of all modified and newly created objects. This minimizes the scope of deployment, besides securing further advantages:
- Fast installation
- No recompilation of unmodified objects, thus excluding a potential source of error
- Minimization of log files, as well as consequent minimization and better management of the time required to control and check deployment
Full deployment and subset deployment can be considered as alternatives. However, these options offer no apparent added value compared to delta deployment. Of course, this always also depends on the conditions of the data warehouse and organizational structures. However, minimizing the scope of a release generally reduces the complexity of the deployment process. Dependencies become more traceable, errors are detected more quickly, and deployment is shortened to a minimum. This achieves transparency, speed and maintainability.
Git in the context of WhereScape RED
Tools like Git are actually intended for distributed version management. A WhereScape application consists of eight .wsl files. Although these files contain metadata, a conventional merge with Git is not possible. Firstly, the metadata are not necessarily sorted, and secondly, a delta procedure at the very latest makes file contents dependent on a specification's scope of deployment. For these reasons, a use of Git functions should be constrained. In our environment, we can use Git as a synchronized storage location for easy transport of developed WhereScape applications to other environments.
Illustrated above is a prototypical process involving development with Git as part of a deployment. The artefact is developed in the DEV environment, and stored locally in a feature branch or specification branch in the Git repository. Once files have been uploaded to the server-side branch ("push"), it becomes possible to switch to another environment and download the branch's contents again ("pull"). This allows artefacts to be installed from the branch's folder structure.
Because not all branches relevant to a release always have to be sought and installed individually, it makes sense to collect successfully accepted artefacts in a separate release branch. Release branches are generated by release management as part of related organizational tasks. Individual feature branches and specification branches must be merged with the release branch. This branch's contents comprising a collection of WhereScape artefacts in a folder structure are accordingly our release. It is then common practice to merge the release branch with the master branch. The master branch serves as a single point of truth and transparent source of release history, given a good folder structure.
In summary, Git in combination with WhereScape assists us in the following aspects:
- Synchronized storage of artefacts
- Transport of artefacts between environments
- Collection of different artefacts
- Access to transparent release history
If you are interested in more information or need assistance with questions concerning WhereScape, DWH automation or deployment and integration procedures, feel free to contact us!
Did you miss part 1 of this article?
