We are using two git branches, one for development and master. When dev
branch is good enough, we merge it to master and then we have a script
which does git pull and restarts uwsgi.
Rok
On Wednesday, February 10, 2016 at 9:50:22 AM UTC+1, Tobias Dacoir wrote:
>
> We've build a small web
Thanks for all the great input. I'll definetely look into salt too (only
worked with puppet so far) but for now I guess fabric will be fine. We are
using Python 2.7 everywhere anyway.
Like I said, right now we plan to host it on a single physical machine that
we get from the university (it's
> I have been through several variations on what you are doing. The
solution which has worked best for me is to use SaltStack to control the
update.
If you are interested in learning SaltStack, I just recently wrote a
step-by-step
tutorial
I have been through several variations on what you are doing. The solution
which has worked best for me is to use SaltStack to control the update. It
will pull your updates using git, apply as needed, and restart your
servers. If you are building a new server (for testing or prototype
Tobias,
I know I will not help you directly, but maybe my setup + process can help
someone else. I am deploying towards Redhat Openshift 2 PaaS.
I was in the similar situation choosing the best fit option for continuous
deployment.
Final process:
- Merging the feature code to the master
The thing is, you should be able to catch those issues when migrating
locally on you development machines. In that case, just fix the migration
and then it should work perfectly in production. You can always add certain
values in the migration scripts themselves.
Regards,
Andréas
2016-02-10
Thanks for sharing your workflow. Sounds simple enough and is more or less
a scripted version of what I had in mind all along.
About the manual intervention: At some points during development we had to
provide a one-time manual entry when Django was migrating the database,
either by adding or
Hi,
What I tend to do when deploying is:
1. Create a fabric script that contains a reference to the server that
should be updated (defaults to dev server).
2. Use git archive to zip the contents of a git tag to a local file.
3. Upload the file to the server
4. Stop the uwsgi process
5. Update
Thanks for the reply.
Thanks for the advice. We should include the migrate command into our git
hook as well. But like I said, sometimes it's not always possible as manual
interaction is required. At least for 1.0 our model should not change much,
except for future extensions and new models.
On Feb 10, 2016 12:50 AM, "Tobias Dacoir" wrote:
>
> We've build a small web application using Django 1.8 over the past couple
of months and we are going live with version 1.0 soon (one last closed beta
test is coming up).
> So far we have deployed it on an Ubuntu VM (in Azure)
We've build a small web application using Django 1.8 over the past couple
of months and we are going live with version 1.0 soon (one last closed beta
test is coming up).
So far we have deployed it on an Ubuntu VM (in Azure) using Apache / Nginx
and a local MySQL Server.
I've already found
11 matches
Mail list logo