Updating your software by upgrading your servers is a common approach followed by most teams today. However, this often leads to configuration drift as ad-hoc modifications are hard to track and apply consistently across all servers. Ultimately, drift leads to deployments that are not always repeatable and consistent. Also, tracking down pesky environment specific bugs becomes impossible since nobody knows exactly what what is unique about the environment.
The Immutable Server pattern addresses this problem by stating that a Server, once deployed, should never be modified. It is only replaced with a new instance updated with the newer version of the machine image. Read more about Immutable Servers here.
To adopt immutable servers, the first step in your Continuous Delivery pipeline must be to build your base machine image. This base image is versioned. Each time your base machine image changes, it should trigger a rebuild for all dependent application images and runs through the rest of your Continuous Delivery workflow. If application code changes, this also triggers a rebuild of the application's machine image and triggers all downstream steps of the CD workflow.
This approach solves drift issues since no ad-hoc changes are every applied to a subset of servers. All machines are always consistent, leading to predictable release and a better night's sleep for everyone involved.
Build custom machine images based on your applications needs. You can also include the application itself in the image to create an immutable machine image that works predictably and reliably each time.
Your machine images are build as part of your overall continuous delivery workflow amd updated automatically when needed. You will never forget to update images again!
Use Packer with Shippable to build images for any cloud like Amazon EC2, Google Compute Engine, Digital Ocean, etc. Spin up machines with your images and run automated tests to make sure they always work as expected.