Continuous Deployment: Version Numbering and Jenkins for Deployment?

2
votes

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.

1
pythonjenkinscontinuous-integrationcontinuous-deployment
Version number depends whose benefit it is for. If it's for advertising then you probably want an incrementing number. If it's for users then either a number or a timestamp. If it's for developers then you probably want to include the git revision (checksum) to save them going somewhere else to look it up. Or create tags, of course. - Steve Jessop
@SteveJessop: Since guettli is talking about prod deployment, you need a tag. IMHO, no release should go to production without being tagged. What you use as your version, is just personal preference. - Peter Schuetze
@PeterSchuetze: seems odd to me to say that it's a matter solely of personal preference how you name your product versions when talking to your customers, but it is not a matter of personal preference whether you use tags or git revisions to identify releases internally (you say one must use tags). Seems to me precisely the reverse, since internal processes can follow your preference whereas externally you have to show something that's vaguely meaningful to its audience. - Steve Jessop
@SteveJessop: Tagging is essential to retrieve the exact version that is out in production and to reproduce the issue faced in production. I am adamant about not using revision numbers, tags are the way to go. However, as you said about version numbers it depends. Personal preference could also mean corporate preference in this case. Version numbers need to make sense (e.g. no counting down). When you go with version numbers, then the question is when do you up the minor and when do you up the major. This is a philosophical question. ... - Peter Schuetze
(continued) ... Going with dates compared to version numbers is fine as long as you don't have several releases a day. When it comes to marketing, then version numbers have as much a meaning as using green or yellow balloons on your next public event. It can mean everything or nothing. However, the Release name/number that is published to the customer does not need to be connected to the internal release number. You actually get in hells kitchen if you try to align them (at least if you do that down to the last digit). .... - Peter Schuetze

1 Answers

2
votes

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.