staging new world order

[Kevin Fenzi]

We agreed at fudcon (well, before then really) that we didn't like some
of the current setup with staging and we were going to redo it. We came
up with some plans at fudcon and I have been working on implementing
those this week. ;) 

So, in the new staging world order how will things work?

EVERYTHING will be in the master puppet branch. 

There is a 'staging' environment. This should be set on any nodes that
are being used for staging. (ie, "$puppetEnvironment='staging'" should
appear at the top of any node being used for staging things. 

Workflow for staging changes: 

1. If you don't need to make any puppet related config changes, don't
do anything. (ie, a new version of an app that uses the same config
files, etc). Just update on the host and test. 

2. If you need to make puppet changes in the module of the application: 

- cp modules/$yourmodulename modules-staging/$yourmodulename
- git add modules-staging/$yourmodulename; git commit -a
- make changes you need to modules-staging/$yourmodulename
- test, make more changes to it, etc. 
- diff -Nur modules-staging/$yourmodulename modules/$yourmodulename and
  check your changes for sanity. 
- rsync -avr modules-staging/$yourmodulename modules/$yourmodulename
- git rm -rf modules-staging/$yourmodulename

3. If you need to make changes outside of your module: 

- Make use of files ending with .staging (see resolv.conf in global for
  an example). So, if there's persistent changes in staging from
  production like a different config file, use this. 
- Conditionalize on environment: 

if $puppetEnvironment == 'staging' {
	yourcode
}
else{ 
	productiononly code
}
- These changes can stay if they are helpful for further testing down
  the road. Ideally normal case is that staging and production pull
  from the same module unless there's active testing of changes being
  made (ie, there is no modules-staging/ unless something is being
  staged.)

Now, hopefully this isn't too much burden on app folks or those who
test with staging. If so, please scream now. ;) 

Additional things we can do: 

Since all the 'in progress' changes are in modules-staging, we can run
a script (once a week?) to list those modules and ask 'hey, are you
still testing this? can it be nuked or merged?' Perhaps with a attached
'diff -Nur modules-staging modules' attached? 

Does this work for everyone? If so, I will make the change in the next
few days and get it done with. I need to work on
app01.stg/app02.stg/proxy01.stg. They will need some config files that
are for staging, but otherwise shouldn't be too bad. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20120313/2548aacf/attachment.sig>