5

We have a new application that needs to be deployed automatically to a number of servers. I need to know if Puppet can be used for the following scenario.

The Application

The application is a combination of .NET and PHP with either a SQL Server or PostGRE database. Database migrations are handled in C# using Entity Framework when the application is first started. The application is not finished but I working through feasibility studies for making deployment automatic.

Build and Continuous Integration

We use Team Foundation Service (TFS) in the cloud for Build.

The target environment

The application will be installed both in the cloud and inside clients' infrastructure. The cloud platform will be controlled by us, so I imagine that's not difficult. I can see the benefit of Puppet for configuring that environment.

However, I may not have too much control about access to the server when it is hosted by a client's infrastructure. I must assume that the server only has access to port 443 (and 80, but I wouldn't update software that way). I imagine we will have administrator access to any servers we need to install to, my concern is more regarding access to the server through a corporate firewall.

The environments will be Server 2008 (IIS7) for .NET web and database servers and possibly a linux server running Apache for PHP. As the application is unfinished, I can't say for sure what the PHP restrictions are just yet. I am assuming that I will have to deploy to two different types of server.

The deploy environment

There will be a server set aside for orchestrating the deployment. Puppet / any other technology can be installed here.

The desired process

Excuse my profuse use of Puppet here. I am unsure of its limitations out of the box and I appreciate that there is a Forge where lots of plugins are available. This level of automation is new to me, so I would be happy to take feedback on my steps!

  1. TFS build completes, unit tests are run and the build is marked as OK.
  2. Puppet spots that there is a new build and grabs the package
  3. Puppet configuration immediately deploys the new package to an integration test server (cloud)
  4. Puppet kicks off MSBuild on the integration test server
  5. Once complete, Puppet updates the state of the TFS build
  6. Puppet Agent on a client server then downloads the new package (pull over SSL)
  7. Puppet waits for an allotted time to install the system (assuming there are no sysadmins awake at this time!)
  8. Puppet sets a flag in a database that all web clients are polling to check for a "shutdown message"
  9. Puppet waits for an allotted time (for users to save their work)
  10. Puppet repoints IIS/Apache sites to a maintenance page
  11. Puppet kicks off backups of code and database
  12. Puppet performs package install, configuration updates on Linux and Windows server.
  13. Puppet triggers smoke tests (.NET console app) and waits for completion
  14. If successful, Puppet repoints IIS/Apache
  15. If not successful, Puppet rolls back both Windows and Linux servers.
  16. Puppet sets flag in database to say that system is live again
  17. Puppet reports back to server.

Assumptions

  • There will be no load balancing, so there will be only one .NET server and one Linux server. This might be required in the future but it might be YAGNI.
Dr Rob Lang
  • 6,659
  • 5
  • 40
  • 60
  • Did you try this? How did it work out for you? Have you compared it to VS Release Management tool? – Shawn Mclean Jan 16 '14 at 17:08
  • 1
    Hi @ShawnMclean, we did try puppet but found that it was not complex enough to handle all our requirements. We ended up calling out to powershell so much that it reduced the usefulness of it. VS Release Management is a push tool, not a pull from server. We ended up writing our own: a windows service sits on the live server and downloads new packages. At allotted time the service performs the release. – Dr Rob Lang Jan 17 '14 at 10:20
  • @Rob VS Release Management is a pull system. Agents poll the Release Management Server at your specified intervals and pull when a new build is available. – JFatt Mar 31 '14 at 16:08
  • @user3481854 Thanks for the tip - RMS was push when the comment was written. It is feature lite, and too late. We've written our own that can deploy to a farm, do rollback on whole farm on a single fail, works with EventStore and Raven backups and a bunch more features that RMS won't have for a while. – Dr Rob Lang Apr 04 '14 at 16:13

1 Answers1

-1

For the client infrastructure, I'd shrink-wrap the product with a Windows Installer MSI. The TFS cloud build sever has Windows Installer XML on it and you can use that to build your installer.

Deliver the installer to the client and have it do all the work. Just like downloading TFS from MSDN and installing it on an on premises server.

You can also publish the MSI on a website and use an autoupdate pattern running on the client to pull it down and execute it.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • 1
    Hi Chris, thanks for your answer. Windows MSI is not the right technology here, I have extensive experience with it and Wix scripts. The MSI cannot be used in distributed environment where you have multiple servers that need to keep their installations in sync. Puppet was also not what we needed, so have written our own pull based system in .NET. – Dr Rob Lang Sep 27 '13 at 10:27