previous article
A lean, sustainable deployment process is essential for rapid, integrated development. The production environment's stability and quality are in the foreground here. Though this can be achieved easily, countless available options and possibilities prevent most people from identifying the basic structure of the process. This blog article describes a simple deployment process which can be extended as required, and leads dependably to success with the help of best practices in the WhereScape RED environment.
Back to Basics: Deployment principles
The primary goal of a deployment process is to safeguard the integrity of the production environment, and ensure that only previously tested objects are released in it.
The standard method to achieve this is to develop objects in a separate environment (DEV). These developed objects are then tested thoroughly in another environment (TEST) which corresponds in many respects to the production environment, and then rolled out at the actual destination, the production environment.
This procedure focuses on testing objects to be released. Each deployment should comply here with the principles of testing (completeness, traceability and reproducibility). Of course, this applies not only to the integrity of objects after deployment, but also the correctness of the elements' contents.
Complex landscapes in the data warehouse area often contain a further instance: The integration environment. Meant for consolidation, this environment is usually used to check releases for technical integrity during installation and rollout.
Git in the context of WhereScape RED
Illustrated above is a simple deployment process. It starts with fulfilment of a specification in the development environment (DEV). After finishing their work, developers test their artefacts with respect to the integration environment. If integrity is ensured, roll-out follows in the test environment. After arrival there, reviews and user acceptance tests are performed.
If changes need to be made to an artefact at any level, the process in the development environment begins again. Once an artefact has been successfully deployed in an environment, the release is extended correspondingly. The released version, in turn, goes through the same entire cycle, and is subsequently installed in the production environment (PROD).
Release cycle
Until a fully automated process (CI/CD) has been developed, it is advisable to issue production roll-outs in a cyclical pattern. This makes it possible to plan and monitor progress, thus increasing transparency in development.
At the same time, the development scope can be well tailored to a cycle, and problems such as simultaneous work on common objects can be reduced. Of course, a cycle's length depends on many factors. One approach involves orientation toward other cycles, such as that of a sprint.
Release management
The release and deployment process is one of the most important in the field of data warehouse management. For this reason, it is useful to introduce an instance which assumes responsibility for this process, while also performing other organizational tasks within the framework of release. This instance is called release management and comprises at least two people. This preserves the two-person rule and promotes review culture during assigned tasks.
Accordingly, for example, a merger of "feature branch" or "specification branch" with "release branch" should only be possible via a pull request. This pull request is then confirmed by release management which checks, for example, whether a specification has actually been approved and further organizational points have been adhered to.
Of course, the quality of a deployment process depends on many factors, including the landscapes of the systems and enterprise. Furthermore, this article clearly presents the concept in a very basic and simplified form. However, a well-structured and lucid process contributes significantly to fast, consistent and transparent development. As a cornerstone for good development work and a secure production environment, it thus deserves the reader's attention.
To discover what else needs to be considered in connection with WhereScape RED and deployment processes, have a look at part 2 of this blog article.
Callback Service