How to do Continuous Deployment for Modern Apps | Agilitest blog

The phrase ‘modern app’ is used frequently in blogs and technical articles, but the definition has always been subjective. When I speak about a modern app, here’s what I have in mind.

What is a modern app?

A caveat — While the article illustrates Continuous Deployment with the use of AWS Services such as AWS CodeDeploy and Amazon Elastic Container Service (ECS), the principles remain the same for the cloud provider and tooling of your choice.

Draw the balance between agility and reliability

Continuous Deployment is one way to get closer to achieving that dream. Along with continuous integration — where developers regularly merge their code changes into a central repository after which automated builds and tests are run — CD is the practice where code changes are automatically prepared for a release to production. Continuous deployment expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage. There can be (and usually are) multiple, parallel test stages before a production deployment. The difference between continuous delivery and continuous deployment is the presence of a manual approval to update to production. With continuous deployment, production happens automatically without explicit approval. As good as pushing that big, red button.‍

(Image courtesy: Amazon Web Services)

How to succeed with continuous deployment?

  • Automatically deploy new changes to staging environments for testing,
  • Deploy to production safely without impacting customers
  • Deliver faster by reducing change lead time and change failure rate.

With the cloud, implementing this practice is easier than ever. Let’s take the example of AWS CodeDeploy which enables automated deployments with virtual servers, containers, serverless and even on-premise workloads.

Continuous deployment applied to AWS CodeDeploy

CodeDeploy needs an Application Specification or AppSpec file to manage deployments. This is typically formatted in YAML (or JSON) and looks something like this:

version: 0.0
os: linux
files:
— source: /
destination: /var/www/html/WordPress
hooks:
BeforeInstall:
— location: scripts/install_dependencies.sh
timeout: 300
runas: root
AfterInstall:
— location: scripts/change_permissions.sh
timeout: 300
runas: root
ApplicationStart:
— location: scripts/start_server.sh
— location: scripts/create_test_db.sh
timeout: 300
runas: root
ApplicationStop:
— location: scripts/stop_server.sh
timeout: 300
runas: root

As you can see, there are different sections in the AppSpec file. Sections such as version and os are self-explanatory. You can set app configurations and also specify the Operating System used.

The ‘hooks’ section contains mappings that link deployment lifecycle event hooks to one or more scripts. Each deployment hook is executed once per deployment to an instance. You can specify one or more scripts to run in a hook. Each hook for a lifecycle event is specified with a string on a separate line. There are different lifecycle events such as ApplicationStop, BeforeInstall, and ApplicationStop so that automated scripts can run at each of these events. For instance, in the ApplicationStart hook, the 2 scripts start a server and create a database. Similarly, the ApplicationStop hook has a script that stops the server.

Understanding deployment types and configurations

Read full article here. An article by Sohan Maheshwar.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store