0

I'm interested to hear how people manage code deployments and how they tie it into their orchestration system.

I've not been able to find a good puppet subversion module which works the way I want. Say I split my application servers into two groups, A and B and I do deploys in a see-saw fashion. What I pictured, is having two variables which define what revision each group should use.

$groupA_svn_tag = 'myCode-1.0'
$groupB_svn_tag = 'myCode-1.0'

Then, when I want to do a deployment, I take groupA off line (in my load balancer) and increment the tag variable.

$groupA_svn_tag = 'myCode-1.1'
$groupB_svn_tag = 'myCode-1.0'

I wait for puppet to do it's thing (svn switch myCode-1.1) and flip the balancer and increment groupB.

Perhaps this is a misuse of puppet as it's more of a 'keep the servers in this state' sort of tool. Should I be using mcollective for this? How do other people approach this problem?

chrskly
  • 1,539
  • 11
  • 16

2 Answers2

1

Most release processes I have come across deploy built artefacts rather than straight checkouts from svn. The management then becomes choosing which version of a file (be it a jar, tar, rpm etc) in a repository to deploy rather than playing with svn tags which is done in a release build process. If my experience holds generally, then maybe that could contribute to the lack of support for what you're trying with svn? Would need some comments from others.

The concept of what you are doing is sound though, but as mentioned. I would do it by failing group A, deploying an artefact 'myCode-1.1.tar.gz' to group A. Then repeat for group B.

Even if your repository is svn, you don't need to mess with tags during the deployment process, just look in HEAD for the required artefact version which can be a part of the puppet manifest you apply to the group.

Matt
  • 1,537
  • 8
  • 11
  • This is a good answer. Makes the release process a bit heavier, but there's a cleaner separation between development and production. An svn tag is, in theory, a snapshot in time. But, really, there's nothing stopping someone committing back into a tag. A package/tarball however, is that bit more frozen in time - especially if you strip out any of the scm bits (e.g., .svn or .git dirs). – chrskly Feb 15 '13 at 12:55
  • same problem however; as in your puppet module you might have a module call myApp to represent the installation and configuration of your app. you then want to say ensure => v1.0 on some systems and ensure => v1.1 on other systems. What I've found useful is abstract out the data from the module (heira is the best tool for the job, but another module to act as an abstraction works well too. Then you want to use MCO or similar to coordinate disabling the puppet agent, then telling certain systems need to check for an update. In this form you seperate the 'How' from the 'What' from the 'When'. – Preflightsiren Feb 23 '13 at 00:04
0

I think that your procedure is good and you should try and use MCollective to manage the puppet runs and taking the nodes out of the balancer if possible. We use SVN extensively for our software and configurations and specifically tag each change/release and then let puppet do its stuff by using vcsdeploy (http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff).

regards

Dave

user1238985
  • 1