With Code Deploy, we provide a method that can be integrated into traditional deployment mechanisms. In this generic approach we do not make any difference whether it is a Magento, Shopware or a PHP/Symfony/Java application.

Let's take a look at the workflow of a deployment for scalable environments:

1. Download and prepare the source code (e.g. Git via SSH)

2. Cache the source code in the form of an archive in a central storage (e.g. AWS S3)

3. Upload the source code to the application instances

4. Start specific installation routines and activate the new source code

5. Adding the completely installed instances to the load balancer (e.g. AWS ELB)

This workflow is started via a script on a so-called Jump Server. A Jump Server is the access point to its root360 cloud environment and is accessible via SSH.

Technically, the process runs through a modular system of several self-contained steps, working with defined input data and generating defined output data. This allows the entire process to be adapted to specific conditions (further process steps, application sources, installation processes). With this flexibility it is possible, for example, to replace services such as AWS S3 or the AWS Load Balancer with other mechanisms by adapting the corresponding step.

This entire process is shown in the following illustration. Behind the process is a collection of Python-based tools and the configuration management system Saltstack. Especially the Saltstack Returner system is used extensively by a special Python library.

Open

By caching the application at a central highly available and secure storage location, (auto)scalability is guaranteed at all times and independent of the external data source (e.g. GitHub). In addition to the system-related proximity, performance is also supported by data compression.

Due to the modular structure of the deployment system, various protocols can be supported and it can be extended similar to a plug-in system. Application-specific installation routines can also be implemented. Furthermore, the deployment system is decoupled from components of the cloud environment in production by modules that function largely independently. A disturbance of the deployment system therefore does not necessarily pose a threat to the operation of the application in the cloud environment and its scalability. The stability of the processes is guaranteed by the use of standard libraries and highly available configuration management systems (Saltstack). Independence from cloud provider-specific systems is thus also possible and even offers the possibility of applying the procedure in on-premise data centers or with other (cloud/hosting) providers than Amazon AWS.

In addition to a completely encrypted data transfer (e.g. Git via SSH, HTTPS and ZeroMQ), Amazon AWS technologies also support the security of the source code of the software. Extensive firewalling, authentication and authorization systems form the basis of a comprehensive security concept for all components and data.

Examples

Below are two scenarios in which we refer to Amazon Web Services (AWS) as an example. The first example shows a simple workflow with Git, while the second example shows a more complex scenario with a Continuous Integration System like Jenkins.

Workflow for a simple setup with Git

Open

1. Developer checks code into Github

2. Developer starts deployment process on Jump Server

3. Deployment system downloads source code from Github

4. Deployment system prepares source code for deployment and uploads it to central storage (e.g. AWS S3)

5. Deployment system transfers the prepared source code onto the application instances, but not yet activated

6. A customer-specific installation routine is started and if successful, the new source code is activated

7. If the application instance was just created and this is its initial deployment, a functioning deployment triggers its activation in the load balancer (e.g. AWS ELB)

Workflow for a more complex setup with external Jenkins

1. Developer checks code into Github

2. Git-Hook launches Jenkinsjob to test and build the application

3. Jenkins successfully assembles the application and makes it available for download

4. Jenkins starts deployment process on Jump Server

5. Deployment system downloads from Jenkins

6. Deployment system prepares source code for deployment and uploads it to central storage (e.g. AWS S3)

7. Deployment system transfers the prepared source code onto the application instances, but not yet activated

8. A customer-specific installation routine is started and if successful, the new source code is activated

9. If the application instance was just created and this is its initial deployment, a functioning deployment triggers its activation in the load balancer (e.g. AWS ELB)

Related tutorials

Related components