Comprehensive analysis of project deployment techniques in Python's Django framework

At the start of a project, a critical moment, the choice will have a long-term impact on the project. There are a lot of tutorials on how to get started with the Django framework, but there is little discussion about how to use Django professionally, or how to use industry-accepted best practices to ensure that your project continues to grow in size. Pre-planning makes it easier for you (and all your colleagues) to move towards the future.

At the end of the article, you will have

• A full-featured Django 1.6 Project
• Source code controlled by all resources (using Git or mercurial)
• Automatic regression and unit testing (using the UnitTest library)
• A setup project that is independent of a specific environment (using VIRTUALENV)
• Automated deployment and testing (using fabric)
• Automatic database migration (using south)
• A scale of your site development workflow

In addition to the first part of the official tutorial in other parts of the tutorial is not. They should be like this. If you want to start a new, production-ready Django 1.6 project, keep looking down.

Prerequisite

It is not necessary to assume that you already know the basics of Python and that some of the previous Django experiences will help. You need Git or mercurial for version control. That's it!
Ready to install

I assume you already have Python installed. If you don't, go to python.org and find the version that matches your system architecture to download the installation. I use a linode on the 64-bit Ubuntu server and I am happy to use the Linode service.

So, what's the first step? Install Django? Not exactly. Installing the installation package directly into your current site-packages has a common problem: if you have more than one Python project on your machine using other libraries like Django, you may encounter problems with application and installation dependencies between repositories. Therefore, we will use VIRTUALENV and its extended virtualenvwrapper to manage our Django installation. This is a practical recommendation for Python and Django users.

If you use Pip to install a third-party library (I don't understand why you're not), you can install Virtualenv and virtualenvwrapper with a simple operation.

$ pip Install Virtualenvwrapper

After installation, add the attached content to your shell launch profile (. ZSHRC,. BASHRC,. profiles, etc.)

The code is as follows:

Export workon_home= $HOME/.virtualenvsexport project_home= $HOME/directory-you-do-development-insource/usr/local/ bin/virtualenvwrapper.sh

Reload your boot profile (source. ZSHRC), and now you're ready.

Create a new environment

Creating a virtual environment is simple, just enter

$ mkvirtualenv Django_project

"Django_project" is the name of your project.

You will notice something that happens immediately:

Your shell is preceded by a "(Django_project)"

Distribute and PIP are automatically installed.

Here is a very useful part of Virtualenvwrapper: it will automatically prepare the environment for you, so that you can use the PIP installation Library immediately. The "(django_project)" section is a reminder that you are using virtualenv instead of Python on your system. To exit the virtual environment simply enter deactivate. When you want to go back to your project and start working, just use Workon django_project. It is important to note that this is different from the vanilla virtualenv tool, where you can run these commands.

Installing Django

"Wait a minute, ' Install Django '?" I've already installed Django! "That's great. But you're not going to use it. Instead, we will use a Django installation on the machine that is managed by virtualenv and will not be messed up by other users (or yourself). To install Django in virtualenv, simply enter:

$ pip Install Django

So the latest version of Django will be installed in your VIRTUALENV environment, you can confirm:

$ which django-admin.py

This will indicate your $home/.virtualenvs/directory. If not, make sure you have "(Django_project)" in your input prompt. If not, use Workon django_project to activate the virtualenv.

Build a project

Before we really start this project, let's talk about it first. I have consulted many Django/python projects over the past few years and have discussed them with many developers. An overwhelming fact is that those with the most difficulty are often not using any version control. That sounds incredible (think about the popularity of GitHub), but developers don't have access to version control at all. Some people think that "this is a small project" and there is no need to use version control. This is wrong.

The tools listed here do not allow you to add additional expense to the use of version control.

Before, I only mentioned git as a (D) VCS. However, since this project is written in Python, mercurial is also a good Python-based option. Because both are more popular, you can find many online learning resources. Make sure you have git or mercurial installed. Both are available through your distro ' s packaging system.

If you're going to use Git,github it's obviously a good option to save your code to a remote repository. With mercurial, Atlassian's bitbucket is a good choice (it also supports git, so you can use Git or mercurial)

(source code) to control your environment

Even though we haven't really done anything yet, we know we want everything under source control. We have two types of "stuff" that will be submitted: your code itself (including templates, etc.) and supporting files, like database fixtures, South Migration (more later) and Requirements.txt files, list all packages that your project relies on, allow automatic build environment (no need to use PIP again Install all packages).

Let's start by creating our project folder. Use the Startproject command provided by django-admin.py to set.

$ django-admin.py Startproject Django_project

We will see that a separate folder has been created: Django_project. Within the Django_project folder, we will see another Django_project folder that contains common elements: setting.py,urls.py and wsgi.py. There are manage.py files within the same level of the second Django_project folder.

Episode: Project vs. application

You may wonder why, in Django1.4, there are commands for creating new applications and adding commands for new projects. The answer lies in the difference between the Django "project" and the Django "Application". Simply put, a project is a complete set of websites or applications. An "Application" is a small, (hopefully) independent Django application that can be used in any Django project. If you are building a blog app called "Super Blog", then "Super blog" Is your Django project. If the "Super blog" supports the reader's vote, the "vote" is a Django application used by the "Super blog". The idea is that your voting application can be applied to other Django projects that require a user's vote, not just in a "Super blog" project. A project is a collection of applications that are built according to project-specific logic. An application can be applied to multiple projects.

While you instinctively tend to include a large number of "super blogs" specific code and information in your "voting" application, there are many advantages to avoid. Based on the loosely coupled principle, writing your application as a separate entity preserves the design intent and avoids bugs in the project that directly affect your application. This also means that if you want, you can send any of your apps to another developer, and they don't need to access or change your main project.

Like many things in software development, it takes a bit of effort, but the payoff is huge.

Create a warehouse

Now we have some "code" in our project (it is really just some stock script and an empty configuration file, as I say), now is the time for us to start our Source control library. Here are the steps implemented in Git and mercurial.
Git

$ git init

This command creates a git repository in the current directory. Add all of our files to git for submission.

$ git Add django_project

Now, we are actually submitting the code to our new library:

$ git commit-m ' Initial commit of Django_project '

Mercurial

$ HG Init

This command creates a mercurial repository in the current directory. Add all of our files to git for submission.

$ HG Add Django_project

Now, we are actually submitting the code to our new library:

$ HG commit-m ' Initial commit of Django_project '

If you're going to use a github or bitbucket, it's time to push the code up.

Using South for Database migration

One of the most frustrating features of Django is managing changes to the model and related changes to the database. With South's help, you can create a complete application without having to write specific database code. South will create a migration file to detect your model changes and generate them automatically in the database. This allows you to move the database forward based on the latest changes, or to cancel a change or a series of changes later. It makes your life so simple that the Django distribution doesn't contain it. It's amazing.

When to start using south

In the previous article, I suggested using South at the beginning of the project. This is good for relatively simple projects. However, if you have a large number of models in your prototype that have changed a lot, it is not the time to use South. The corresponding, just throw away and rebuild the database when needed. You can write scripts that form a database that has some test data and edit them as needed. However, once your model no longer changes, start using South as soon as possible. This is simple:

Setup and Setup

Still in our virtual environment, install South like this:

$ pip Install South

We add south to Installed_aps in the project's settings.py file. Now add, including the database settings in your project, and then run Python manage.py syncdb. You will need to elevate permissions using the Super username and password (you can type and then enter). More importantly, South has already set up the tables it needs to use in the database.

You might realize that we didn't add the app to the project, but just ran the syncdb. Doing this first allows South to be installed at the beginning. With South, all of the migration work in our app can be done, including the initial migration.

As we have just completed a lot of changes, it will now be a good time to commit. You have to adapt to frequent submissions, knowing that the smaller the granularity of submissions, the higher the degree of freedom to rollback on error.

To commit, let's take a look at all those changes.

(git)

$ git status# on branch master# changes not staged for commit:#  (use "git add 
 
  
   
  ..." To update what would be Committed) #  (use "Git checkout-- 
  
   
    
   ..." To discard changes in working directory) # #    Modified:  django_project/settings.py## untracked files:#  (use "git add 
   
    
     
    ..." to include in what'll be Committ ED) # #    django_project/.settings.py.swp#    django_project/__init__.pyc#    django_project/settings.pyc
   
    
  
   
 
  

(Mercurial)

$ HG statusm django_project/django_project/settings.py? Django_project/django_project/.settings.py.swp? Django_project/django_project/__init__.pyc? Django_project/django_project/settings.pyc

Using Git and Mercurial, you may find files that you never want to commit, such as the Python-compiled. pyc file that appears above, and the Vim. SWP interchange file. to ignore these files, create a. gitignore or. hgignore file in the root directory of the project and add a shell pattern in which to match the files you do not want to track. For example, most of my file content is:
?

The code is as follows:

*.pyc.*swp

Before we submit, there is also a message to check: We have installed the Python package. We want to be able to track the names and versions of the Python packages we use, so that we can easily rebuild our production environment. Pip just has a command that can fulfill our needs.

$ pip Freeze > Requirements.txt

I saved the PIP output to a file named Requirements.txt and added the file to the code control. In this way, we always have a list of updates that contain the packages that will be used.

Now add settings.py and Requirements.txt to the submission file and submit:

$ (GIT/HG) Add django_project/settings.py requirements.txt$ (GIT/HG) commit-m ' Added South for Database migrations '

New settings

As developers become more comfortable with Django and Python, they will find that settings.py is a simple Python script that can be "written". A common way to settings.py is to move from a rather quirky project folder to a new folder called Conf or config. Be aware that you need to make minor changes to manage.py to adapt to this movement.

Within setting.py, Installed_apps will quickly become a bunch of third-party packages, self-Django applications and project-specific applications. I'm used to dividing Installed_apps into three categories:

1. Default_apps: The Django Framework app as part of the default Django installation (like admin)
2. Third_party_apps: Like South
3. Local_apps: The app you created

This makes it easier to see which third-party apps you use, and which are the projects themselves. Just remember that there is one last line and the following similar code:

Installed_apps = Default_apps + Third_party_apps + Local_apps

Otherwise, Django will have an error that does not define INSTALLED_APPS.

Create our App

Use manage.py in a normal way to create an app (Python manage.py startapp MyApp) and add it to Installed_app. Also, it takes time for manage.py to execute (chmod +x manage.py) So you can just type in the./manage.py instead of always entering Python manage.py . To be honest, few developers do that. I can't figure out why.

The first thing we need to do before adding a model is we tell South that we want to use it for migration:

$ python manage.py schemamigration MyApp--initial

This will create a porting file to apply our model changes to the database (if we have one) without having to completely destroy and rebuild it. It also allows us to restore changes when the situation deviates. We use the porting file to migrate the changes to the database (even if it hasn't changed), the command is as follows:

$ python manage.py migrate MyApp

South is smart enough to know where to find the transplant files and remember the last transplant we made. You can specify a separate migration file, but this is not generally necessary.

When we finally make changes to the model, we use the following command to let South create a migration file:

$ python manage.py schemamigration MyApp--auto

This detects the model in MyApp and automatically adds, deletes, or modifies the tables in the database accordingly. You can then apply the changes to the database using the migration command as above.

Development Area

One more thing you need to note: Separate the development area from the file you have identified, for obvious reasons. Using git and mercurial to implement this is simple and also helpful for deployment. Create a directory outside the directory where the Django_project is located as your development area (I call it dev).

In your development directory, use Git or mercurial to clone the current project:

$ (GIT/HG) clone/path/to/my/project/

Two tools will create a full copy of the library. All changes, branches, and history will be available in the new library. From now on, you should work in your development directory.

Because it's easy to branch with git and mercurial, you create a branch when you switch to a large change in a new branch or site. Here are the two tools to implement the method:
(git)

$ git checkout-b 
 
  

This not only creates a named new branch, but also checks out the code. Almost all development work should be on the branch so that the main branch can be restored at any time.
(Mercurial)

$ HG Branch 
 
  

Please note that the branch in the mercurial community is a controversial topic and there are currently some options available, but there is no "clearly correct". Here, I use the naming branch, which is probably the safest and most beneficial branching style. Any commits after the branch command will take effect in the new branch.

Using Fabric for Deployment

Then we have a Django application. How are we going to deploy it? Fabric. It is a waste of time to discuss anything else for a reasonably sized project. Fabric can be used for a number of different purposes, but it's really good at deployment.

$ pip Install Fabric

Fabric needs a fabfile file called fabfile.py, which defines all the actions we can take. Now we're going to create it. Write the following to fabfile.py and drop it into the project's root directory.

From Fabric.api import localdef prepare_deployment (branch_name):  local (' Python manage.py test django_project ')  local (' git add-p && git commit ') # or local (' HG add && Hg commit ')

This will run the test and commit your changes, but the submission takes place only under the condition that the test passes. Here, a simple pull action in the production environment can be the actual deployment. We add something to the actual deployment. Add the following to fabfile.py:

