node-grunt-compass Heroku's Buildpack analogy for AWS CodeDeploy?

Question

We are trying to move from Heroku to AWS CodeDeploy for my nodejs app.

In Heroku deployment, we are using nodejs-compass-grunt buildpack to install dependencies and run compass. Is there anything similar in AWS to use with CodeDeploy, or shall we just have an AMI with eveyrthing installed?

Answer 1

Unlike Heroku, CodeDeploy is not a PaaS. It is a service that help you manage the software deployed to cloud infrastructure. CodeDeploy is agnostic to the type of software you want to deploy and it's dependencies. This makes it very flexible, but it also mean you have to do more work to tell CodeDeploy how to deploy your software.

If you want to deploy a framework to your hosts and then deploy your software that depends on that framework, you have two options:

1. Bake an AMI with your dependencies already installed and then only deploy your service.
2. Install all your dependencies as part of the CodeDeploy deployment.

With Option 1, if you want to migrate to a new version of any of your dependencies you will have to do the same work you would need to do to switch to a new OS. Essentially you will have to a blue-green deployment:

1. Bake a new AMI.
2. Provision new infrastructure.
3. Deploy your service to the new infrastructure.
4. Replace your existing infrastructure with the new infrastructure.
5. Release your old infrastructure.

That can certainly slow things down if you were looking to do in place deployments wit CodeDeploy. If you want to do blue-green deployments anyway, than the only thing you are losing is not using a vended AMI and having to manage your own.

With Option 2, you need to bundle all your dependencies as part of your deployment archive. You will also need to create scripts to install/reinstall them. You can then call these scripts during the BeforeInstall lifecycle step. When you want to update or rollback a dependency, all you need to do is the same thing you would do for normal code changes:

1. Create a new deployment bundle. (This should ideally be end result of your build process when using CodeDeploy)
2. Deploy the new bundle using CodeDeploy.

The downside in here is that you have to either reinstall your dependencies on every deployment or add code to check the existing version and risk having a corrupted dependency that won't just be fixed by redeploying the same bundle.