We use Chef for both config management (making sure a “DB Node” has the right version of the right DB on it; that an “App Server” has the right version of Java and env vars on it, etc.). as well as deployment (chef-client --once) of our apps to the appropriate app server nodes.
To me, personally, I feel like deployment belongs in the realm of the CI server. Everything besides the app (the container, the OS, system tools, system config, etc.) belongs to config management, and is therefore best managed by tools like Chef, Puppet, etc.
Currently, our CI builds produce an artifact (an executable JAR with an embedded Tomcat container), and then executes the Chef-Client on all the nodes where the JAR needs to be deployed. The Chef-Client is configured to pull the JAR from the CI server. This feels hacky to me, and I’m trying to research a better, more cogent solution.
So I ask:
- Does deployment belong to the CI server, or to the CM tool? Why?
- If it belongs to the CI server, what mechanisms (SSH, SCP, etc.) should the CI server be using to actually perform the deploy? We use Bamboo but could just as easily be talking about Jenkins, Hudson, etc.
- There is a difference between deploying (placing the app on the node) and running. Does running belong to the CI server as well, the CM tool, or some other process? In other words, what should actually stop the “old” version of the app, replace it with the “new” version, and then start the new version? Is this a candidate for something like Run Deck?
2
I suspect the answers are going to be largely opinion based, and reflect the political atmosphere of the companies people work for, but here goes…
I would say everything starts with “why?” Why do we build apps? To fulfill business goals. Why do we build infrastructure? To run apps that fulfill business goals. So it seems that there’s a natural hierarchy here. CI servers build apps and test them on something. CM tools build servers. So, a properly configured DevOps chain probably uses CI servers to invoke CM tools to make sure that the place they’re about to deploy to is configured properly. Then, once tests pass, those same CI servers invoke deployment tools (if necessary) to push code to production servers that could be built with CM scripts on a moment’s notice if necessary. In other words, the scripts become the definition of what’s there — no changes are made to the servers that aren’t scripted first. As far as bouncing the existing app, that’s going to depend on the configuration of your infrastructure. If you can smoothly take an app server offline (without affecting users), deploy new code, run a smoke test, and bring it all back online in a rolling script across a farm of servers, that’s what you’re shooting for — continuous delivery capabilities that don’t affect end users.
2
My opinion is that Deployment belongs to CI server. A CM tool like chef is to build your infrastructure to the desired state. But deployment is more than that. Suppose you have to deploy a system that includes a front-end web application to multiple load balanced servers, some DB change scripts and a few back-end services to another set of servers. There are dependencies and order involved in the deployment. e.g. DB changes before back-end services to all servers and before front-end web app. There may be actions needed to be taken if there is error at any step. Chef as I understand cannot handle this kind of scenarios whereas any competent CI tool would.
The other issue is often times infrastructure is shared among multiple apps and is patched/updated in a different cadence to the apps and indeed one app should not upgrade the infrastructure as it doesn’t own it. This is another reason to keep CI and CM separate.
1