5

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?
Improve this question
2

2 Answers 2

Reset to default
4

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.

Improve this answer
2
  • Thanks @Joe ROunceville (+1) - after reviewing the play it seems that deployment/bouncing (stop old, swap old for new, start new) is one in the same. So is it fair to say that you're a proponent of the CI tool invoking a deployment tool, whose job should be to do the deploy/bounce? Thanks again!
    – herpylderp
    Aug 1, 2014 at 19:54
  • Yes, if you're going for a true DevOps chain, basically everything is optimized from the tester/developer's perspective. That is to say, in a DevOps chain, code+tests get checked in, and if regression tests + new tests pass, the code moves to production. So that means the CI server is driving. Before you go too far down that path though, it's imperative that operations, change management, developers, and testers are all on the same page -- you're taking the training wheels off. Your tests become the proof that your app is working. In most shops that elevates their importance dramatically.
    – Calphool
    Aug 4, 2014 at 18:00
0

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.

Improve this answer
1
  • 2
    Chef can do pretty much anything. It's Ruby scripting, and the Chef server can be queried for pretty much anything you choose to have the nodes publish. For example, let's say you want to add a node into an app server tier. Obviously this involves a lot of setup beyond setting up the app server itself. To do this properly, you set up your Chef recipes so they ask about the environment and trigger dependent recipes (for load balancers or any other device that needs to know about the new server). So really it's all about what your organization chooses to do. There's no "default right way".
    – Calphool
    Jan 13, 2015 at 17:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.