Continuous Deployment: Version Numbering and Jenkins for Deployment?

Question

We want to use continuous deployment.

We have:

• all sources (python) in a local RhodeCode (git) server.
• Jenkins for automated testing
• SSH connections to the production systems (linux).
• a tool which can update servers in one command.

Now something like this should be implemented:

1. run tests with Jenkins
2. if there is a failure. Stop, mail developers
3. If all tests are OK:
4. deploy

We are long enough in the business to write some scripts to do this.

My questions:

How to you update the version numbers? You could increment them, you could use a timestamp ...

Since we already use Jenkins, I think we do it in a script called by Jenkins. Any reason to do it with a different (better) tool?

My fear: Jenkins becomes a central server for things which are not related to testing (deploy). I think other tools like SaltStack or Ansible should be used for this. Up to now we use Fabric (simple layer above ssh). Maybe we should switch to a central management system before starting with continuous deployment.

Answer 1

Since we already use Jenkins, I think we do it in a script called by Jenkins. Any reason to do it with a different (better) tool?

To answer your question: No, there aren't any big reasons to not go with Jenkins for deployment.

Pros:

• You already know Jenkins (and you probably know some of the quirks)
• You don't need to introduce yet another technology
• You said that you want to write scripts called by Jenkins, so you can switch easily to a different system later.

Cons:

• there might be better tools out there for deployment
• Does not tie the best with Change Control tools.

Additional Considerations:

• Do not use the same server for prod deployment and continuous build/integration. These are two different tasks performed by two different roles. Therefore two different permission schemes might be employed.
• Use permissions wisely. I use two different permissions for my deploy and CI servers. We have 3 Jenkins servers right now.
  1. CI and deploy to uncontrolled environments (Developers can play with these environments)
  2. Deploy to controlled environments. (QA environemnts and upwards)
  3. Deploy to prod (yes, that's the only purpose in live of this server.) with the most restrictive permission scheme.
  4. sandbox, actually there is this forth server for Jenkins admins to play with.
• Store your deployable artifacts outside of Jenkins (and you do if I read your question correctly).

So depending on your existing infrastructure and procedure you decide for the tooling. Jenkins won't log you in as long as you keep as much of the logic as possible in scripts that are only executed by Jenkins.