Wednesday, July 31, 2013

Git WinRM Automatic Deployment

The Challenge - Give development teams the ability to deploy their applications simply and in real-time without giving them administrative access to the destination Windows and Linux servers.

The Solution - A professional Git based deployment system; like that you find on GitHub, Heroku, and other leading cloud services. This solution goes a step further by providing the ability to deploy to Windows servers using Windows domain authentication and WinRM.

The Benefits - Lightning fast, easy to use, secure, reliable, and accurate; no opportunities for accidental installation errors; and with perfect history, easy to snap-back to previous deployments.

How It Works

  1. User checks-out the desired deployment branch of their local repository
    (dev for development enviro, test for test enviro, etc.)
  2. User copies the deployment files to their local repository
  3. User enters a descriptive message regarding this deployment and commits their changes
  4. User pushes their changes to the remote repository
  5. Git hook in the remote repository examines branch being updated and determines the destination server
  6. Git hook issues windows remote command to execute installation script on the destination server
    (issues SSH remote command for Linux servers)
  7. Installation script on the destination server retrieves the latest deployment files from the remote repository using Git
  8. Installation script installs the files
  9. Installation script emails the results which include the user’s identity and commit message

Technologies and their Roles

  • Git - Deployment engine, file transport, and version control
  • Cygwin - Deployment hub, SSH server, and Linux / Windows authentication integration
  • WinRM - Secure shell services for Windows
  • OpenSSH - Secure shell services for Linux
  • Python - Installation scripts that are easy to read / maintain / extend

Architecture Notes

  • Made extraordinary effort to keep setup simple as possible with minimal customization - focus on leveraging core strengths of existing proven products
  • One shared repository per application, with separate branches for each environment
  • Developer workstations use a default install of Git
  • Developer workstations access remote repository on Deployment Server using SSH keys for a special deployment user - password is never shared
  • Deployment server uses default Cygwin install with the OpenSSH server and Git packages
  • Deployment server setup to run OpenSSH server as the special deployment user
    (see Cygwin reference below)
  • Deployment server configured to disallow shell access / constrain developers to Git commands only
    (see Pro Git reference below)
  • Deployment server’s remote repository includes simple post-update hook
    (see sample included with the IIS Web Deployer script)
  • Special deployment user is given administrator authority on destination server
  • Destination servers use the OS’s built-in remote services technology, using their defaults
  • Destination servers use a default install of Git
  • Destination servers require installation script for the application being deployed
    (see IIS Web Deployer script)


Updates since original posting:
2013.11.06 - Corrected reference for Cygwin OpenSSH setup and added backup copy
2013.10.31 - Improved post-update Git hook example to show IP of the deployer
2013.08.22 - Improved interaction with Git remote repository