[datr]

How does this work with:

1) Clusters of application servers, where I will only want operations on shared resources to fire from one of the servers? E.g. database updates, shared file changes, etc.

2) When I want to deploy the code to a different location on the server so that I can have multiple versions of the application available? Do I have to spin up new servers for each version?

3) You mention roll back by just specifying an earlier package but I don't see how this would work with stuff like database changes either.

[mbreese]

You're over thinking this... None of these are specific to this type of deployment. If you want to do any of the above, you'll have to work around whatever production deployment solution you have.

1) How would you do this for any deployment method? You'd have to be able to ID one specific node in the cluster or make sure that your job could only run on one node with some sort of locking.

2) If you're deploying multiple versions of an application in production, you have other issues.

3) How would you rollback database changes to begin with? Come to think of it, how are you going to deal with any DB schema changes? This isn't just an issue with .deb/.rpm deployments of code - you'll have to figure this out for any application deployment.

[datr]

Well, I suppose I mention some of these as the article likens package deployment to Capistrano in the opening paragraph.

Using Capistrano, for (1) I can just mark a target server as the update server to run these commands. With packages, I assume I either have to have a different version of the package or rely on some sort of environmental variable which the package reacts to?

2) Yep that would be slightly ridiculous for production, but I was thinking more along the lines of UAT, staging and other shared testing/development environments. It's not ideal but I have been in the situation where this was required.

3) True, but with Cap I can just issue a rollback and it will revert to a database snapshot that was taken from the last version. I can't see how we could do something like this with packages alone.

Maybe you mean that these problems are outside the scope of packages and that I should be using packages with something like capistrano to solve them but then why wouldn't I just use Capistrano on its own?

[cauliturtle]

For (2), > Our goal is to be able to install a package using Puppet, Chef, CFengine, or something else that puts all of your code in a standard location every time, on every server.

For (3), I think it can be solved by some database migrate library?

[datr]

I suppose (1) could be set by solved by having an environment variable where a server can be nominated as the "update server" but this has the down side of it still being possible to accidentally have multiple marked servers.