cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge pull request #11409 from erikdw/staging-instead-of-stage

Browse source 
change 'stage' to 'staging', as it a much more common term for a pre-…
This commit is contained in:
Toshio Kuratomi 2015-06-27 06:31:57 -07:00
commit 6daae92e73
3 changed files with 18 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
docsite/rst/playbooks_best_practices.rst
View file

@ -28,7 +28,7 @@ Directory Layout
The top level of the directory would contain files and directories like so:: The top level of the directory would contain files and directories like so::
production # inventory file for production servers production # inventory file for production servers
stage # inventory file for stage environment staging # inventory file for staging environment
group_vars/ group_vars/
group1 # here we assign variables to particular groups group1 # here we assign variables to particular groups
@ -78,9 +78,9 @@ If you are using a cloud provider, you should not be managing your inventory in
This does not just apply to clouds -- If you have another system maintaining a canonical list of systems This does not just apply to clouds -- If you have another system maintaining a canonical list of systems
in your infrastructure, usage of dynamic inventory is a great idea in general. in your infrastructure, usage of dynamic inventory is a great idea in general.
.. _stage_vs_prod: .. _staging_vs_prod:
How to Differentiate Stage vs Production How to Differentiate Staging vs Production
````````````````````````````````````````` `````````````````````````````````````````
If managing static inventory, it is frequently asked how to differentiate different types of environments. The following example If managing static inventory, it is frequently asked how to differentiate different types of environments. The following example
@ -285,14 +285,14 @@ all the time -- you can have situational plays that you use at different times a
Ansible allows you to deploy and configure using the same tool, so you would likely reuse groups and just Ansible allows you to deploy and configure using the same tool, so you would likely reuse groups and just
keep the OS configuration in separate playbooks from the app deployment. keep the OS configuration in separate playbooks from the app deployment.
.. _stage_vs_production: .. _staging_vs_production:
Stage vs Production Staging vs Production
+++++++++++++++++++ +++++++++++++++++++
As also mentioned above, a good way to keep your stage (or testing) and production environments separate is to use a separate inventory file for stage and production. This way you pick with -i what you are targeting. Keeping them all in one file can lead to surprises! As also mentioned above, a good way to keep your staging (or testing) and production environments separate is to use a separate inventory file for staging and production. This way you pick with -i what you are targeting. Keeping them all in one file can lead to surprises!
Testing things in a stage environment before trying in production is always a great idea. Your environments need not be the same Testing things in a staging environment before trying in production is always a great idea. Your environments need not be the same
size and you can use group variables to control the differences between those environments. size and you can use group variables to control the differences between those environments.
.. _rolling_update: .. _rolling_update:

10
docsite/rst/test_strategies.rst
View file

@ -114,14 +114,14 @@ Testing Lifecycle
If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy. If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy.
As such, deploying into a local development VM and a stage environment will both validate that things are according to plan As such, deploying into a local development VM and a staging environment will both validate that things are according to plan
ahead of your production deploy. ahead of your production deploy.
Your workflow may be something like this:: Your workflow may be something like this::
- Use the same playbook all the time with embedded tests in development - Use the same playbook all the time with embedded tests in development
- Use the playbook to deploy to a stage environment (with the same playbooks) that simulates production - Use the playbook to deploy to a staging environment (with the same playbooks) that simulates production
- Run an integration test battery written by your QA team against stage - Run an integration test battery written by your QA team against staging
- Deploy to production, with the same integrated tests. - Deploy to production, with the same integrated tests.
Something like an integration test battery should be written by your QA team if you are a production webservice. This would include Something like an integration test battery should be written by your QA team if you are a production webservice. This would include
@ -213,7 +213,7 @@ If desired, the above techniques may be extended to enable continuous deployment
The workflow may look like this:: The workflow may look like this::
- Write and use automation to deploy local development VMs - Write and use automation to deploy local development VMs
- Have a CI system like Jenkins deploy to a stage environment on every code change - Have a CI system like Jenkins deploy to a staging environment on every code change
- The deploy job calls testing scripts to pass/fail a build on every deploy - The deploy job calls testing scripts to pass/fail a build on every deploy
- If the deploy job succeeds, it runs the same deploy playbook against production inventory - If the deploy job succeeds, it runs the same deploy playbook against production inventory
@ -241,7 +241,7 @@ as part of a Continuous Integration/Continuous Delivery pipeline, as is covered
The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your
QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like
to run against the stage environment on every deploy. Obviously at the development stage, unit tests are great too. But don't unit to run against the staging environment on every deploy. Obviously at the development stage, unit tests are great too. But don't unit
test your playbook. Ansible describes states of resources declaratively, so you don't have to. If there are cases where you want test your playbook. Ansible describes states of resources declaratively, so you don't have to. If there are cases where you want
to be sure of something though, that's great, and things like stat/assert are great go-to modules for that purpose. to be sure of something though, that's great, and things like stat/assert are great go-to modules for that purpose.

12
plugins/inventory/ec2.ini
View file

@ -91,10 +91,10 @@ group_by_rds_engine = True
group_by_rds_parameter_group = True group_by_rds_parameter_group = True
# If you only want to include hosts that match a certain regular expression # If you only want to include hosts that match a certain regular expression
# pattern_include = stage-* # pattern_include = staging-*
# If you want to exclude any hosts that match a certain regular expression # If you want to exclude any hosts that match a certain regular expression
# pattern_exclude = stage-* # pattern_exclude = staging-*
# Instance filters can be used to control which instances are retrieved for # Instance filters can be used to control which instances are retrieved for
# inventory. For the full list of possible filters, please read the EC2 API # inventory. For the full list of possible filters, please read the EC2 API
@ -102,14 +102,14 @@ group_by_rds_parameter_group = True
# Filters are key/value pairs separated by '=', to list multiple filters use # Filters are key/value pairs separated by '=', to list multiple filters use
# a list separated by commas. See examples below. # a list separated by commas. See examples below.
# Retrieve only instances with (key=value) env=stage tag # Retrieve only instances with (key=value) env=staging tag
# instance_filters = tag:env=stage # instance_filters = tag:env=staging
# Retrieve only instances with role=webservers OR role=dbservers tag # Retrieve only instances with role=webservers OR role=dbservers tag
# instance_filters = tag:role=webservers,tag:role=dbservers # instance_filters = tag:role=webservers,tag:role=dbservers
# Retrieve only t1.micro instances OR instances with tag env=stage # Retrieve only t1.micro instances OR instances with tag env=staging
# instance_filters = instance-type=t1.micro,tag:env=stage # instance_filters = instance-type=t1.micro,tag:env=staging
# You can use wildcards in filter values also. Below will list instances which # You can use wildcards in filter values also. Below will list instances which
# tag Name value matches webservers1* # tag Name value matches webservers1*