I need some help to find a deployment strategy

[Sabine Maennel]

I have my site up and running for the first time, and it was hard to catch the deadline, but now I need to get to a more professional setup of things. 
Can anybody help me with this please:

So on my host I have two installations : Test and Live
I guess that is fine, right?

So now on bitbucket I just opened a repository for the deployment. I remeber my hoster telling me I should do that.

Then I have a second repository for development on Bitbucket.

Do I need anything else? Is that the right approach. How will be the workflow from deployment through testing into the live site.

Let me guess.
If I want to take something live: it would be the following steps:
commit in my development repository

copy the changes in my live repository,
send it to the testing area, 

test 

commit the live repository when the new version is okay and put it live at the same time

Do test and live have different wsgi files or the same? 

Do I provide the wsgi files or does the hoster do that?
Do I use the same settings in both test and live environment?

My hoster said I could directly deploy from bitbucket, but I do not know how. Do you have suggestions on this.

Does that strategy sound right to you over all or am I missing something important here. 

Thanks for all the help I got so far in this forum. I really appreciate this and will try to give back at a later time

with kind regards 

     Sabine Maennel
 
 

[Mark Phillips]

Sabine,

How I deploy a django app...ymmv and I won't say this is the best way to do it....;)

I have two machines - one for development (my laptop) and one for production (a hosted site) on Linode. The development machine uses virtualenv and runserver to test etc. The production machine uses virtualenv, Apache, and mod_wsgi to serve the django pages.  I only use one GIT repository for all my code. I use fabric to deploy to production from git, or to revert to an older version if for some reason the new version breaks something on the production machine. I save a few past versions on the production server.

I realize that the best approach is to test on something identical to your production server, but I have not had any issues going from runserver testing to mod_wsgi. I can always create a staging environment on my development server that uses apache and mod_wsgi in a separate virtualenv and stage a deployment there, but I haven't hit that particular problem, yet. That is also why I made sure to test the fabric script for rolling back to the previous version on the production server. If I hit a snag, I just roll back and then work on the problem off line from the production server.

Some references -

Django, Apache, mod_wsgi - https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/

Django and fabrik - https://django-fab-deploy.readthedocs.org/en/0.7.5/

Google will also find many useful sites for deploying using fabric. It took a little learning time to get it all to work (virtualenv, git, fabric, mod_wsgi, django), but the end result was well worth the leaning time. When I develop, test, and deploy I spend 99% of my time on the development and test part of the process.

Since Linode, as a production host, is only a virtual server, I had to provide all the necessary files to make it all work together.

I am happy to provide more details, but since my process is a little different from the one you outlined, I thought I would just give you an outline at this point. Someone else may have a solution closer to the way you seem to be going. All roads lead to Rome...just find the one that works best for you.

Mark

P.S. I would recommend a lot of testing from development through deployment before you actually go live. Make sure the process works end to end...once you go live, there is no turning back! ;)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b38240ac-5791-485d-8fed-ec8a278026b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lachlan Musicman]

I can't recommend the Two Scoops of Django method enough, if only
because it's made by people that deploy a lot and from sensible
suggestions.

1. Just a single code base, but with different branches if needed
(hence using DVCS). Then you commit once, and have no synchronisation
problems. Any issues in the dev code base you fix immediately it
doesn't work in staging or production
2. I have three sites - dev, staging, production, because you would
not believe the things I break on first deploy (to staging)
3. Each set up can happen on the same machine - but in different
Virtual Envs and wsgi files
4. settings.py becomes settings/base.py settings/dev.py settings
production.py settings/staging.py
5. the wsgi is generic, checked into codebase, then excluded in
.gitignore. Then each is changed - just that one line referencing
settings.
6. Different requirements.txt, to keep on top of which environments
are using which add ons. Production doesn't need django-debug, all
need python-ldap/django-auth-ldap, but only after the deployment of
ldap worked in dev, then staging...

Check out two scoops - I think it's chapters 3 and 4

cheers
L.
4.

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b38240ac-5791-485d-8fed-ec8a278026b6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You have to be really clever to come up with a genuinely dangerous
thought. I am disheartened that people can be clever enough to do that
and not clever enough to do the obvious thing and KEEP THEIR IDIOT
MOUTHS SHUT about it, because it is much more important to sound
intelligent when talking to your friends.
This post was STUPID.
-----------------------------------------------------------------------------------------------------------
The Most Terrifying Thought Experiment of All Time
http://www.slate.com/articles/technology/bitwise/2014/07/roko_s_basilisk_the_most_terrifying_thought_experiment_of_all_time.html

[Sabine Maennel]

Dear Marc, thank so much for this detailed response, I will study these links and decide what to do. I am actually already live and went up under a lot of time pressure, but with a temporary site. So I guess I can still fix the process, but the right time for this is now before the site gets out of control. I really appreciate your advice on this and will check out fabric.

       with kind regards
            Sabine Maennel

[Sabine Maennel]

Thank you Lachlan for your advice, I will check out Two scoops of Django on that. I have it at home. Thanks for being so patient and helpful.

   with kind regards 
        Sabine