Here's a broad overview of the process. We are surprisingly close...
- Code for the project (webapp/website/windows service) sits in TFS
- The GO build agent is on a Windows server w. Visual Studio - it builds the project
- Have the config files changed? If so, this process is still manual - thankfully rare, should just be an onboarding task
- On the build agent, git commit the built files and config files
- After the commit, get your latest version number and apply a label into the TFS project noting the associated git hash (so when troubleshooting, we say 'it's this git hash version we're running', and they say, 'oh, what label in TFS?' - now we have an answer! (co-worker came up with this idea)
- Git houses built project files and project config files
- Git also houses the Chef config files
- Chef will be run to re-configure IIS (if necessary), operate services/appPools, and...dun dun dun...run a git fetch! (or git clone, not sure yet) Bam! New code!
- External tests will confirm things are ok. (internal tests will be part of the entire process, too)
- QA now needs to automate their tests
- Deploy to UAT
- UAT now needs to automate their tests
- Deploy to PROD
- UAT/ProdSupport now need to have automated smoke tests
We're choosing to handle the environment specifics like this: Pipeline steps for each environment deployment, so just customize the pipeline to say 'use MY config files', rather than all sorts of complicated logic.
Yay! Getting there...
Other fun features we're going to bundle into this new process:
- Re-organized config files - i.e. putting site-level stuff once at the site level, instead of once inside each confif file
- configSource config files (as mentioned, will be used to deal with environment-specific settings)
- IIS-level config, doing it right - every time!
- GO pipeline - this is going to be the showpiece, so we'll have to make sure it works brilliantly