Continuous delivery: Deploy, upgrade, and deliver

The purpose of Continuous delivery is to be able to quickly deliver customizations and extensions of your project to production, without interrupting the work of the Live environment, without having downtime, or without the need to manually merge configurations or databases. You ensure your application functions as expected using thorough automation tests on a production-like environment. Propelling the changes through the environments is automated, which makes it more reliable.

The main goal of the process is that after every development iteration, you end up with the same setup, which you started with - code is the same on all environments, the latest database is on the Live environment.

The following chart displays a simplified overview of a Continuous delivery process:

During delivery of source code to a Staging or Live environment some of the environment configurations need to be different. For example, API keys for different connectors and SMTP server settings, which is necessary because you do not want to spam the live accounts with test data.

Continuous delivery automates the delivery of configurations from Development to Live environments. This way, you do not need to manually apply transformation to configurations.

• Environment configurations
  Environment configurations are delivered with the source code and, therefore, must not be saved in the database. This is because, database is never pushed from Development to Test or Live environments. It is pulled from Live, so that new code changes can be tested against actual live application data.

  NOTE: Labels and messages (resource files) are stored as configurations and not in the database. Therefore, changes to them should pass through the continuous delivery process and not be done on your live environment.        

• Application settings
  On the other hand, there are the application configurations that need to be changed during runtime. Application configuration is a setting that is related to the applications actual functionality and is modified on the Live environment runtime. These settings need to be saved in the database, so that they are not overwritten with each subsequent delivery of code.

The following flowchart demonstrates the flow of code and database:

Generally, in a Continuous delivery process, you have the following environments:

• Development environment
  This is the environment where you develop your project. Usually it integrated a source control system. There you develop, extend, and configure your project and, then, build it and run unit tests and integration tests.
• Test environment
  This is the environment where you only run tests, such as UI automation tests, performance and security tests. You can change the test, but not the code in this environment. To perform the tests, you can create and delete content, but if you need to fix something in the code, you need to go back to the development environment.
• Live environment
  This is the environment that displays your public website. This is where the backend users can create content, change runtime setting, manage websites, but cannot change the code and the configurations of the project. This is the environment where the frontend of the website is accessible to public users.
  If you need to change the code or the configurations, you need to go back to your development environment.

You can setup a Continuous delivery process for new, as well as existing projects. You can setup the process, regardless of how many existing environments you are currently using, and regardless of where your project is currently deployed or where you want to deploy it. You can also setup the process with a SiteSync environment, used to synchronize content.

Your Live environment can be located on various locations, such as Amazon Web Apps, Azure Cloud Services, on a Virtual Private Server, etc.
For all available deployment options, see Deployment.