o Keep
at least two environments in clouds
·
"Last Known Good" environment
§ To
be used for testing, stakeholder demos, or perf/load/stress testing
·
"Latest Build" environment
§ May
have any build on it, and may or may not work depending on what ever else is
going on.
§ This
environment can also be used for any kind of destructive testing, since any
test that shouldn't be interrupted should be run in the "LKG"
environment.
·
Alternating the environments (Env1 and Env2)
§ In
practice, you can get this effect by simply alternating environments that you
deploy your build to.
§ So
Env1 gets Build 1, Env2 gets Build 2, then Env1 gets Build 3. Then, if build 4 fails BVT's in Env2, You'll
still have Build 3 in Env 1. Build 5
should then still go to Env2, and this should continue until a stable build
exists in Env2.
§ Ideally,
this means the most recent two builds will always be deployed, unless one build
fails.
o The
cloud test environment should be as "real" as possible.
·
Best case, you use production versions of all
dependencies, real certificates, real domain names, and production-identical
configuration settings.
·
This isn't always practical (for example cache
durations are frequently lower in test than prod to allow content to expire
more rapidly), but the closer you can get to this, the less surprised you'll be
when you go to production.
o Do
at least one cloud update each day, or even more often
·
This helps stabilize deployment tools, encourage
cloud-based testing (code won't be too stable to test), and get people familiar
with what can go wrong in the cloud, and how to fix it.
No comments:
Post a Comment