Advice for Blue between switching to Green and back to Blue? about docs-dev-guide HOT 2 CLOSED

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/143507247

The labels on this github issue will be updated when the story is started.

from docs-dev-guide.

I'll offer some strong support for always deploying completely fresh from source (and secrets) through a pipeline, from the practice of immutable infrastructure. Emphasis in all the quotes is my own.

• Martin Fowler suggested regularly tearing down servers and rebuilding them from source (PhoenixServer, 2012):

  The primary advantage of using phoenix servers is to avoid configuration drift: ad hoc changes to a systems configuration that go unrecorded. Drift is the name of a street that leads to SnowflakeServers, and you don't want to go there without a big plough.

• Kief Morris explains the one-way flow of configuration from source to deploment in terms of CI/CD (ImmutableServer, 2013):

  By frequently destroying and rebuilding servers from the base image, 100% of the server's elements are reset to a known state, without spending a ridiculous amount of time specifying and maintaining detailed configuration specifications.

  Once you've spun up a server instance from a well-tested base image, you shouldn't run configuration management tools, since they create opportunities for untested changes to the instance. Any changes that are needed can be made to the base image, tested, and then rolled out. Servers without the change are torn down and replaced.

• Chad Fowler (no relation) likens it to immutable data structures in functional programming (Trash Your Servers and Burn Your Code, 2013):

  [A]n old system inevitably grows warts. They start as one-time hacks during outages. A quick edit to a config file saves the day. Application code is deployed outside of the normal straight-from-source-control process. The system becomes a house of cards. You fear any change and you fear replacing it since you dont know everything about how it works.

  If you absolutely know a system has been created via automation and never changed since the moment of creation, most of the problems I describe above disappear. Need to upgrade? No problem. Build a new, upgraded system and throw the old one away. New app revision? Same thing. Build a server (or image) with a new revision and throw away the old ones.

• HighOps brings the idea of immutable infrastructure right to the level of the application instance (Immutable Infrastructure: what is it?, 2014):

  So what is an Immutable Infrastructure?

  A pattern or strategy for managing services in which infrastructure is divided into "data" and "everything else". "Everything else" components are replaced at every deployment, with changes made only by modifying a versioned definition, rather than being updated in-place.

from docs-dev-guide.