Continuous delivery is the principle of building applications that can be released safely to production at any time, on-demand. To accomplish this, you need a deployment pipeline that can rapidly assess the impact of changes made to your applications (from a production readiness perspective) and deploy them to production in a swift manner, with the least amount of intervention required from a human operator.
We recommend a delivery pipeline comprised of 5 distinct environments, as depicted in the following picture:
The step-by-step guide Building an OutSystems continuous delivery pipeline with Jenkins allows you to build the pipeline described in this article using Jenkins.
Soon, OutSystems will make available an open-source project containing all the tools needed to build an OutSystems pipeline that integrates with your existing CI/CD tools. These tools include Python scripts and pipeline templates that will simplify adapting an OutSystems pipeline to your specific use cases, and we will be able to accept contributions from the community to help evolve and improve them.
The sections below describe each stage of the recommended OutSystems pipeline in more detail.
Development (DEV) is the primary environment for developing your OutSystems applications. Once the development of a new feature or change request is complete, developers can create a release candidate by tagging one or more LifeTime applications and providing a meaningful version number and description for each one, according to the changes made.
The act of tagging applications in LifeTime is what defines the scope of changes (or changeset) to be validated by the pipeline. This action is known as the commit stage and serves as the trigger for running the continuous delivery pipeline.
Following the commit stage, the newly created LifeTime tags are automatically deployed to the Regression (REG) environment where an automatic regression suite is run to assess the deployability of the latest code version of your applications. This regression suite includes the unit tests written earlier during the development phase, and may also include other elements like UI tests (for critical end-user flows) or code analysis procedures.
To enable a successful continuous delivery practice in your low-code factory, it is highly recommended to develop your applications with testability in mind. This means not only complying with development best practices (such as the 4-Layer Canvas) that promote proper isolation of business concepts in your architecture, but also ensuring that your developers write unit tests as part of their development activities.
The proposed approach relies on unit tests written with the BDD Framework Forge component for the automatic regression stage. This article provides additional insights on how to write tests using this framework. Also, as a best practice, consider isolating your unit test code in separate LifeTime applications to prevent it from being deployed to production along with your application code.
If the regression suite is executed successfully in REG, then the release candidate versions are automatically deployed to the Acceptance (ACC) environment where they will wait for approval by a business representative. In the meantime, this environment allows for manual and exploratory testing of the release candidate, much like a Quality Assurance environment of a typical low-code factory.
Pre-production and Production
After the release candidate is accepted by the business, deployment to the Production (PRD) environment is triggered by an authorized user using a "push-button" approach. This means that pushing a button (literally!) is all it takes to perform the necessary actions for deploying to production a release candidate that has successfully gone through your deployment pipeline.
Although it is technically possible to have a deployment pipeline with less environments than the proposed configuration, it should be noted that such an option would increase the risks associated with your delivery process: for example, promoting a new release candidate for acceptance without going through an automated regression check first, or deploying changes to production without dry-running them in a production-like environment first.