(Beginnings of a Staging SOP) |
(Update git instructions, add note about fileserver.) |
||
Line 28: | Line 28: | ||
<pre> | <pre> | ||
git clone /git/puppet/ | git clone /git/puppet/ | ||
git | git checkout --track -b staging origin/staging # This only needs to be run once on the initial clone | ||
# make changes, git commits | # make changes, git commits | ||
git push | git push | ||
git checkout master # switch back to the master branch | |||
git checkout staging # switch back to the staging branch | |||
</pre> | </pre> | ||
{{admon/note| On staging, for files not in modules (ie stuff in configs/*), puppet will use what's in the master branch for those files (TODO: confirm this statement more completely).}} | |||
== Troubleshooting and Resolution == | == Troubleshooting and Resolution == | ||
[[Category:Infrastructure SOPs]] | [[Category:Infrastructure SOPs]] |
Revision as of 03:31, 13 August 2009
We have the ability to create a staging environment in Infrastructure. This attempts to duplicate a small section of our infrastructure for testing purposes. If there's a large scale change that you need to perform, it's a good idea to push the changes to the staging environment first and check that everything works properly and that you have puppetized all the necessary changes before pushing the changes live.
Contact Information
Owner: Fedora Infrastructure Team
Contact: #fedora-admin
Persons: mmcgrath
Location: Phoenix
Servers: (proxy1.stg, db1.stg, app1.stg, app2.stg fas1.stg)
Purpose: Staging environment to test changes to apps.
Using
Puppet
Staging servers are managed through puppet so that you can test config changes in puppet before pushing live. You need to use a different branch to push to the staging servers. Basic steps:
git clone /git/puppet/ git checkout --track -b staging origin/staging # This only needs to be run once on the initial clone # make changes, git commits git push git checkout master # switch back to the master branch git checkout staging # switch back to the staging branch