I have a multi-step deployment system setup, where I develop locally, have a staging app with a copy of the production db, and then the production app. I use SVN for version control.
When deploying my production app I have been just moving the urls.py and settings.py files up a directory, deleting my django app directory with rm -rf command and then doing an svn export from the repository which creates a new django app directory with my updated code. I then move my urls.py and settings.py files back into place and everything works great.
My new problem is that I am now storing user uploads in a folder inside of my django app, so I can't just remove the whole app dir anymore or I would loose all of my users files.
What do you think my best approach is now? Would svn export --force work, since it should just be overwriting all of my changed files? Should I take an entirely new approach? I am open to advice?
You may want to watch this presentation by Jacob. It can help you improve your deployment process.
I use Bitbucket as my repo and I can simply perform push on my Dev box and run pull/update on Stage/Prod box. Actually I don't run them manually, I use fabric to do them for me :).
Your could use rsync or something similar to backup your uploaded files and use this backup when you deploy your project.
For deployment you could try to use buildout:
http://www.buildout.org/
http://pypi.python.org/pypi/djangorecipe
http://jacobian.org/writing/django-apps-with-buildout/
For other deployment methods see this question:
Django deployment tools
You can move your files to S3 servers (http://aws.amazon.com/s3/), so you will not ever have to care about moving them with your project.
Related
I'm attempting to deploy a Django app via docker, first locally, and then to a cloud server. I could not find an answer to my initial question before I attempt this: if I run docker-machine create, I'm guessing this should be run from within my virtualenv, right?
This would then grab all of my specific app dependencies, and begin to build certificates to throw in the container? If not, please explain otherwise..
Yes you are correct.
I will try to help you by my experience, if you wanna deploy django apps via docker.
First you need to setup docker machine in your local machine. Please see the
instruction. By default driver that will be used is --driver
virtualbox default.
List what kind of specifics dependencies images of your apps. Ex:
you need nginx, postgres, uwsgi, or you need to fetch an image then
modified that image you can use dockerfile (its the best practice
for you).
I suggested you to use docker-compose. Really its make our project
pretty easy to manage. You have to define all images that you need
for your app in docker-compose file Please read this reference.
After you finished develop your app then you want to deploy in production server (cloud) you just need to copy all your project then running your docker-compose. All images dependencies will be automatically pulled in the cloud.
As a reference, you can see this project (this is an open source project that I developed.) On that project, I use make file to manage docker-compose command and it make easy to manage.
An example of dockerfile
An example of docker-compose.yml
An example of Makefile
Hope this will help you.
I am planning on moving from "EmberJS" to the Ember-cli, though I have a small problem. Is it possible only to run file watcher instead of serving/using ember serve that will run local server? As I am running my PHP backend on the Google App Script I have already a local python HTTP server running in localhost:8080 I do not need another one to run in localhost:4200
If I don't run ember serve my local changes in development environment wont get updated. Is there a better way of doing this? Is it possible to use assets in the app folder when running in development environment? and use dist folder for staging/live environments?
As mentioned in the guide, you can use the build command with the --watch flag.
ember build --watch
That will keep rebuilding your changes but not actually run the server.
As for your second question:
Is it possible to use assets in the app folder when running in development environment? and use dist folder for staging/live environments?
I don't believe so. You can change the output-path property in your .ember-cli config file, but you can't have one that's specific to a certain environment. You could always write a quick script to move the files though. :)
I have an ember-cli app that is deployed in S3. It works well, and I have Travis set up to deploy changes when there is a merge into the master branch in GitHub.
But sometimes I want to test a change in the deployment environment without a commit -- perhaps because it can only be tested in that environment, like a fix to a mobile-only defect.
So I tried:
ember build --environment=production
followed by:
aws s3 cp dist/ s3://my_bucket/ --recursive
which uploaded things to my bucket. But the page didn't work, my browser told me there was a redirect loop. It wasn't a code issue, because when I pushed the changes to master, Travis successfully deployed them to S3.
Is there something clearly wrong with what I did, copying the dist folder to my bucket?
I'm using Ember-cli 1.3.1, if that matters.
I suggest you use ember-cli-deploy works pretty and support several plugin in order deliver your code much more easier.
I haven been using it for a while a work pretty well.
http://ember-cli.github.io/ember-cli-deploy/plugins/
I'm new to django and my very first project is my blog. I wonder how django developers who use pydev normally synchronize with remote hosting server, updating their sites?
I also would like to know, how do you combine usage of git with a django project? Should I just make a repository for the entire project?
At my company we've got an entire git repository for each project, including the Django sources that are put in the PYTHONPATH for each project, making Django versions project dependant. The folder structure is something like:
/.git
/projectname/app1
/projectname/app2
/projectname/manage.py
/django-lib/django/...
As django-lib is not a Python module, we include both / and /django-lib in the PYTHONPATH. If your project is becoming large, you might want to consider using git submodules on your apps.
We've also setup several servers to support the developers. There's a testing server running a central testing database and a setup including Apache with WSGI to make testing on a real server possible, which sometimes is a bit different then the local manage.py the developers use before committing their changes.
The testing server is updated with the master branch of our git repository. We've made several scripts to allow all developers to do this without letting them login to the server via SSH, but that is just during pre-release. After release, that server will become our staging server, and we'll remove all scripts from it to make it just like our production server.
Every developer has setup their local project to make sure that it communicates with the central testing database, containing several test data. I myself push my changes from the commandline, but you could also use EGit for this.
When we've got a release, we put it in a separate branch, called 'release' (obviously) and the production server will pull only from that branch. This is done via SSH, but I don't really know how your server setup looks like, so I guess that that last step is entirely up to you.
I hope that this has helped you a bit. I won't say that this is the best workflow possible, but it works for us and you should figure out what works for you.
Most experienced Django developers use pip(or distribute) and virtualenv deal with all the python packages you might need for your Django projects (including Django itself).
Personally, all I keep in my projects git repository is a bunch of segregated requirements lists generated by pip :
. ~/Dev/environs/$PROJECT_NAME/bin/activate
pip freeze > ./docs/requirements/main.list
I'm fairly sure most django developers would be familiar with Fabric, which I use for :
streamlining local interaction with git and,
pushing to our central repository,
pulling from our production or test server
touching the wsgi on the relevant server
and pretty much any other kind of task you might find yourself using ssh terminal session for.
For those cases where I need to make changes to someone elses django application in order to make it work or suit our purposes, I :
fork it on github,
clone from my forked repo
make the changes
push it up to my own repo
and provide merge requests to the original repo owner
This way, i have a repo where i can use pip requirement lists to keep pulling from until the original application owner gets their own repo updated.
This is specific to my current project. But maybe the answers will reveal some more generic solutions.
Here is the situation:
I develop django project on my Windows box
I use SVN to commit to a SVN repository
while developing I use development server that comes with django
There is a testing server (apache) that runs somewhere else, and everytime i finish something I need to manually copy my work via WinSCP/Putty and make sure it works on testing server
Testing server is accessible for our testers to use and test and report bugs
I would like to automate this process as it is very painful. It involves me to export the whole repository, copy to the testing server, get rid of the pyc files, sometimes restarting apache, use the correct settings.py (usually some renaming).
I would like to for the testing server to automatically retrieve new files after each SVN commit. I could write a custom script to do all this stuff, but something tells me that there are some easy-to-use solutions I could use to change my workflow to make things less painful.
One extra bonus. There is a designer that works on HTML/CSS on the templates directly on the testing server. I need to check whether he made changes and I transfer them to my computer and subsequently to SVN rep. My boss thinks it's too dangerous to give him SVN access. Any ideas to help me out with this, also?
deployment:
I would say its better to do the deployment the same way you do for the production. Fabric is a good solution.
SVN way:
If you want to do it in the SVN way, create a branch called testing, once you have a working version of your code and ready for testing merge the development branch to the testing branch. Make sure you have permission on the testing branch to restrict everyone from merging to the test branch. After merging the test team should take a update to a specific version.
.pyc
It unnecessary to manually remove pyc files you can add a svn hook which can ignore the pyc files on commit. Create a file .svnignore
*.pyc
and run this command
svn -R propset svn:ignore -F .svnignore .
If you’ve already got yourself into the mess of versioning your compiled files, then you can do either of these things.
find -name "*.pyc" -exec svn revert {} \;
find -name "*.pyc" -exec svn delete {} \;
Django settings file
You can set the environment variable through which django can take up corresponding settings file. Django set env
Designer
well designer working directly on the test server is not a bonus point. :) its a headache. In a ideal environment no one should touch the code in the testing server. Create a separate branch for the designer or he can commit to the dev branch which all the developers can merge.
One option is to create a read only svn user and have it checkout the svn repository on the apache server. Then to do a build you run 'svn update'. You can check if the designer modified files by doing a 'svn status'.
If your svn repository is on the same machine as your qa django instance you could use a post-commit hook to have it svn update after each commit, and bounce apache if needed. See http://subversion.tigris.org/faq.html#website-auto-update