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?