Friday 4 November 2016

Keep Calm! Deploy to Production!

Welcome to the latest JenkinsHeaven post!

This week I completed the extension of our deployment capability of the web app from our Jenkins Master (running in the Test domain) directly to the Production Support environment (running in the production domain). Thus demonstrating that this set of mechanisms will work for the Production environment (also in the production domain).

The domains have made things tricky.

The trick was:

  • Build on the master and restore all NuGet packages (from both nuget.org and our internal NuGet server)
  • Use the Archive for Clone Workspace SCM Post Build step to archive the entire workspace (**/*.*). See Clone Workspace plugin
  • On success kick off a downstream job tied to the slave (running on Production Support IIS box)
  • First step of downstream job (running on slave) select "Clone Workspace" from the list of possible SCMs and select the parent project
  • I have a step that automates backing up the web application files (just in case the deployment fails for some reason)
  • Deploy with MSBuild as before!
  • Success!

Till next time.

2 comments:

  1. Intrigued by your use of your source control manager to keep your workspace (using the clone workspace plugin). Is there a workspace archive for each branch? Push to branch, triggers job, tests pass, archive to Git repo (just one, that is used for all branches, or to branch specific repo?)

    ReplyDelete
    Replies
    1. Hi Brave Lad,

      We are using TFS Plugin. Master branch of each application represents latest and greatest and spawns release branches.

      Every successful build is labelled. We deploy by label.

      I wrote a separate system called the Build Dashboard that shows what's deployed where and when.

      Patch releases to production just keep getting added to the end of the release branch.

      Thanks for the question. Hope this makes sense.

      Delete