TFS & GO & Chef, oh my: Part 5 - Build repo solved!

One of the senior tech folks had some great input for how the process should work.  I'd been wondering about what to use as a build repository - had hoped we could use Git - and sure enough he suggested using Git!

Before:

  1. Project is built (raw files)
  2. Files are zipped
  3. Zip filename and an injected file have version#s
  4. Update symlinks to latest/previous?
  5. Chef handles IIS/win svcs
  6. Deploy latest zip via Chef
  7. Inject appropriate configs
After:
  1. Project is built (raw files)
  2. Files are checked in to Git
  3. Chef handles IIS/win svcs
  4. Git fetch for latest
  5. Inject appropriate configs
So Chef will be handling IIS configuration & services, and then just running a git fetch (or git clone for new installs) to update the files.  Because each step of the pipeline is configurable, we don't even need to 'figure out' what environment we're deploying to.  So this means when we deploy to QA, we specify to copy the QA scripts.

Another interesting concept is 'the config files rarely change'.  This means the onboard (bringing projects into the automation pipeline) process will look like this:
  1. Get TFS project path - is it a setup project or something else? (build reqs)
  2. Configure new project pipeline in GO (use template)
  3. Configure new build repo path (automated into git script?)
  4. Re-jig configuration files for multi-environment (configSource recycling)
One area to investigate with GO is to see if we can set up a dashboard with the latest pipeline activity - i.e. if something has made progress recently, show that at the top.  It's looking like we'll probably have 50+ pipelines if we use the 'every project gets a pipeline' theory.  Maybe there's a better way...hm.

Comments

Popular posts from this blog

DFSR - eventid 4312 - replication just won't work

Fixing duplicate SPNs (service principal name)

Logstash to Nagios - alerting based on Windows Event ID