1

I am a one man team. I develop an in house database, and the web interface.

My current workflow is code on my development machine. Test.
Push to a central git server.
Log into the production server pull the changes over. Restart the production server.

It's Python based. I tried setting up Fabric one time, but I felt it was a fair bit of setup, and I didn't really gain anything, as such I didn't end up using it.

Would someone like to convince me otherwise? (Or agree).

On a side note, is Hudson/ Jenkins doing the same job as Fabric? Or are these for different purposes. Am I misunderstanding the concepts?

gnat
  • 21,442
  • 29
  • 112
  • 288
wobbily_col
  • 1,861
  • 3
  • 16
  • 25

1 Answers1

3

Fabric is a deployment tool, not a CI server. Jenkins is and its awesome. Its basically a glorified script-runner that's integrated into your SCM (with lots of extras), so it looks at your SCM and runs scripts when commits are made. One of those scripts will be to deploy automatically.

A CI server is basically an automated way of performing half the tasks you did manually. Instead of logging into the production server, pulling the changes and restarting it, Jenkins can do it instead. (However, production sounds warning bells to me, you really want to do this to a QA server to test again and make sure its right before copying to production as a manually-invoked controlled process).

Still, if a CI server is set up to deploy from a know position on your SCM (eg latest from trunk) then you just have to commit changes - and after a short while, its on your QA server. If you had a test team, you might set this up to deploy overnight so they could come in and begin testing against latest code without having to worry about getting the latest deployed.

CI servers are also used to build (might not be applicable to you), run static analysis tools (always a good idea) and run tests scripts.

One thing that might be worrying if the push-pull nature of your work. You should be working on a branch, then merge that to master when its ready. Your CI server should be watching master so you can work as much as you like on your branch before hitting the 'merge which triggers all the deployments' button.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • As a Python application, there isn't really a build step. I don't see any advantage in recreating the virtual environment every time. I see what you say about branches, but as a one man team,I don't end up using them too much. Maybe these points are why I can't see a great deal of advantage in the extra overhead. – wobbily_col Mar 25 '15 at 09:14
  • 1
    there may not be a *compile* step, but there's more you can do in a build phase such as run tests, analysis and/or document generation. – gbjbaanb Mar 25 '15 at 10:15
  • 1
    @wobbily_col What do you mean by extra overhead? If you set up CI once, then you never have to do it ever again. And then everyday when you're about to do those things manually that are instead being handled by the CI Server, go and drink a beer or something – Brandin Mar 25 '15 at 13:44
  • Yes, and it isn't a trivial task setting up a CI system. I already have plenty of other tasks to do. As a one man team I seem to spend a similar amount of time fixing my automated systems as the time they save me. On larger projects this would be a no brainer, but for me I am unsure if I am gaining or loosing. It definitely adds extra complexity to the project. – wobbily_col Mar 25 '15 at 16:20
  • Try jenkins - it is really easy to set up, keep up to date, and configure. If you have scripts that do your deployment (surely you do...) then it can checkout and run them for you. The big deal about doing this, is that it forces you to make your deployments repeatable. Can you revert a deployment to production without a load of manual steps? If your process was automatic then you would be able to quite easily. Things like this are the difference between an amateur and a professional. – gbjbaanb Mar 25 '15 at 17:26