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?

Modern applications are built with modular architectural patterns, serverless operational models, and agile developer processes. They allow you to innovate faster, reduce risk, accelerate time to market, and decrease your total cost of ownership (TCO). One of the ways for a business to iterate and innovate faster is to adopt modern DevOps practices — especially CI / CD. This is another phrase that you have likely come across at a conference or in the media. CI / CD is short for Continuous Integration / Continuous Deployment. In some cases the ‘D’ also stands for ‘Delivery’ but for the purpose of this article, we will go with Deployment. If you have ever wondered how to modernize your app by adopting CD best practices, this article is intended for you.

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

The dream of every developer has been to write code, hit a big red button and then see this code in production. This can be a good or a bad thing. In some ways, this is the most agile any development process can be. Who needs checks and balances, amirite? But this is also a *very* bad thing. Bugs, and errors can crash your application and give your customers a terrible experience. So how do you 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?

The goals for effective continuous deployment are

• 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

Here’s an example of how AWS CodeDeploy automates your deployments on Amazon ECS. (This assumes you have the prerequisites of an app running on AWS with the relevant IAM permissions and policies.)

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

So, you’re managing your deployments with an AppSpec file, that is just the start to an automated deployment. The next step is to determine how to eliminate downtime, and minimize errors to ensure that your customers are not impacted…

Read full article here. An article by Sohan Maheshwar.