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.