CODEWITHSUNDEEP
djangodeployment
Hellnar
Hellnar

Reputation: 64793

Django and multi-stage servers

I am working with a client that demands multi-stage server setup: development server, stage server and production/live server.

Stage should be as stable as it can be to test all those new features we develop at the development server and take this to the live server in the end.

We use git and github for version controlling. I use Ubuntu server edition as the OS.

The problem is, I have never working in such multi-stage server plan. What software/projects would you recommend to do a proper way of handling such setup, especially deployment and moving a new feature developed to the stage and then to the live server ?

Upvotes: 12

Views: 1503

Answers (3)

Bernhard Vallant
Bernhard Vallant

Reputation: 50776

There is a nice branching model for git (as it is also used by github itself for example). You can easily apply this branching model using git-flow, which is a git extension that enables you to apply some high level repository operations that fit into this model. There's also a nice blogpost about this.

I do not know what exactly you want to automize in your deployment workflow, but if you apply the model mentioned above, most of the correct version handling is done by git.

To add some further automatic processing to this, fabric is a simple but great tool, and you will find many tutorials about its usage (also in combination with git).

For handling python dependencies using virtualenv and pip is for sure a very good way to go.

If you need something more complex,eg. to handle more than one django instance on one machine and for handling system wide dependencies etc checkout puppet or chef.

Upvotes: 4

Issac Kelly
Issac Kelly

Reputation: 6359

Try Gondor.io or Ep.io, they both make it pretty easy (gondor especially excels in this area) to have two+ instances with very similar code, from your VCS -- and to move data back and forth. (if you need an invite, ask either in IRC, but if I recall, they're both open now)

Upvotes: 2

Josh Smeaton
Josh Smeaton

Reputation: 48710

We use two different methods of moving code from environment to environment. The first is to use branches and triggers with our source control system (mercurial in our case, though you can do the same thing with git). The other, is to use fabric, a python library for executing shell code across a number of servers.

Using source control, you can have several main branches, like production development staging. Say you want to move a new feature into staging. I'll explain in terms of mercurial, but you can port the commands over to git and it should be fine.

hg update staging
hg merge my-new-feature
hg commit -m 'my-new-feature > staging'
hg push

You then have your remote source control server push to all of your web servers using a trigger. A trigger on each web server will then do an update and reload the web server.

To move from staging to production, it's just as easy.

hg update production
hg merge staging
hg commit -m 'staging > production'
hg push

It's not the nicest method of deployment, and it makes rolling back quite hard. But it's quick and easy to set up, and still a lot better than manually deploying each change to each server.

I won't go through fabric, as it can get quite involved. You should read their documentation so you understand what it is capable of. There are plenty of tutorials around for fabric and django. I highly recommend the fabric route as it gives you lots more control, and only involves writing some python.

Upvotes: 7

Related Questions