Comprehensive analysis of project deployment skills in the Python Django framework page 1/2

This article comprehensively analyzes the deployment skills of the Python Django framework, including Fabric and other aspects of automated deployment and unit testing. we strongly recommend that you! If you need it, you can refer to it as a critical moment at the beginning of the project. There are a lot of tutorials on how to get started with the Django framework, but few talk about how to use Django professionally, or how to use industry-recognized best practices to ensure continuous growth of your project scale. Advance planning makes it easier for you (and the lives of all colleagues) to move towards the future.

At the end of the article, you will have

• A full-featured Django 1.6 project
• All resources controlled by source code (using Git or Mercurial)
• Automatic regression and unit testing (using the unittest Library)
• An installation project independent of a specific environment (using virtualenv)
• Automated Deployment and testing (using Fabric)
• Automatic Database migration (using South)
• A development workflow to scale your site

None of the first tutorials are available at home and abroad. They should. If you want to start a new, ready-to-use Django 1.6 project, continue with this article.

Prerequisites

It is assumed that you have understood the basic knowledge of Python and some previous Django experiences are helpful, but this is not necessary. You need git or Mercurial for version control. That's all!
Prepare for installation

I suppose you have installed Python. If you do not have one, go to python.org to find the version that matches your system architecture and download and install it. I use a 64-bit Ubuntu Server on Linode, and I am very happy to use the Linode service.

So what is the first step? Install Django? Not all. Installing the installation package directly to your current site-packages has a common problem: if more than one Python project on your machine uses other libraries such as Django, you may encounter dependencies between applications and software libraries. Therefore, we will use virtualenv and its extension virtualenvwrapper to manage our Django installation. This is a practical suggestion for Python and Django users.

If you use pip to install third-party libraries (I don't know why), you can install virtualenv and virtualenvwrapper through simple operations.

$ pip install virtualenvwrapper

After installation, add the following content to your shell startup configuration file (. zshrc,. bashrc,. profile, and so on)

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 startup configuration file (source. zshrc). now you are ready.

Create a new environment

It is easy to create a virtual environment, just enter

$ mkvirtualenv django_project

"Django_project" is the name of your project.

You will notice something happening immediately:

Add "(django_project)" to your shell )"

Distribute and pip are automatically installed.

This is a very useful part of virtualenvwrapper: it will automatically prepare the environment for you, so that you can use pip to install the library immediately. The section "(django_project)" reminds you that you are using virtualenv instead of Python on your system. To exit the virtual environment, simply enter deactivate. To get back to your project and start working, you only need to use workon django_project. Note that this is different from the vanilla virtualenv tool, where you can run these commands.

Install Django

"Wait, 'Install Django '? I have installed Django !", Great. But you won't 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, just enter:

$ pip install django

In this way, the latest version of Django will be installed in your virtualenv environment. you can confirm as follows:

$ which django-admin.py

This will indicate your $ HOME/. virtualenvs/directory. If not, make sure that "(django_project)" is displayed in your input prompt )". If not, use workon django_project to activate virtualenv.

Create a project

Before we start this project, let's talk about it first. I have consulted many Django/Python projects over the past few years and discussed them with many developers. The overwhelming fact is that the most difficult things often do not use any version control. This sounds incredible (think about GitHub's popularity), but developers will not be exposed to version control. Some people think that "this is a small project" and there is no need to use version control. This is incorrect.

The tools listed here will not allow you to add more additional expenses to use version control.

Previously, I only mentioned git as (D) VCS. However, since this project is written in Python, Mercurial is also a good choice based on Python. Because both of them are popular, you can find many online learning resources. Make sure that you have installed git or Mercurial. Both of them can be obtained through your distro's packaging system.

If you plan to use git, GitHub is obviously a good choice to save your code to a remote repository. If you use Mercurial, Bitbucket of Atlassian is a good choice (it also supports git, so you can use git or Mercurial)

(Source code) controls your environment

Even if we haven't done anything yet, we know that we want to keep everything under the control of the source code. There are two types of "things" that will be submitted: The Idea File, listing all the packages on which your project depends, and allowing automatic environment Building (you do not need to install all the packages using pip install again ).

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

$ django-admin.py startproject django_project

A separate folder named django_project is created. In the django_project folder, we can see another django_project folder containing common elements: setting. py, urls. py, and wsgi. py. There is a manage. py file at the same level in the second django_project folder.

Episode: Project vs. Application

In Django1.4, you may wonder why the command for creating a new application also needs to be added. The answer is the difference between Django "project" and 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 application called "Super Blog", "Super blog" is your Django project. If "super blog" supports voting by readers, "voting" is a Django application used by "Super Blog. This concept requires that your voting application be applied to other Django projects that require user voting, rather than just the "super blog" project. A project is a collection of applications built according to the specific project logic. An application can be applied to multiple projects.

Although you may instinctively prefer to include a large number of "super blog" specific code and information in your "vote" application, avoiding this has many benefits. Based on the principle of loose coupling, writing your application into an independent entity can maintain the design intent, and avoid project bugs directly affecting your application. This also means that if you want to, you can send any of your applications to another developer, and they do not need to access or change your main project.

Like many things in software development, this requires a little effort, but the return is very generous.

Create a repository

Now we have some "code" in our project (it is really just some stock scripts and empty configuration files, so I will say so ), now is the best time for our initial source code control Library. The following steps are implemented in Git and Mercurial.
Git

$ git init

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

$ git add django_project

Now, we can submit 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 our files to git for submission.

$ hg add django_project

Now, we can submit the code to our new library:

$ hg commit -m 'Initial commit of django_project'

If you want to use GitHub or Bitbucket, it's time to push the code.

Use South for database migration

One of the most frustrating features of Django is the changes in management models and databases. With the help of South, you can create a complete application without writing specific database code. South China will create a migration file to detect your model changes and automatically generate them in the database. This allows you to migrate the database based on the latest changes, and to cancel a change or a series of changes. It makes your life so simple. it is surprising that the Django release does not include it.

When to start using South

In the previous article, we recommend that you use South from the very beginning of the project. This is good for relatively simple projects. However, if a large number of models have changed significantly in your prototype, it is not the time to use South. Correspondingly, only the database is lost and rebuilt as needed. You can write scripts to construct databases with some test data and edit them as needed. However, once your model does not change, you can use South as soon as possible. This is simple:

./manage.py convert_to_south 

Installation and setting

Still in our virtual environment, install South as follows:

$ pip install south

Add South to INSTALLED_APS in the settings. py file of the project. Add now, including the database settings in your project, and then run python manage. py syncdb. You will need to upgrade the permission to use the super user name and password (you can enter and press enter ). More importantly, South has already set the tables it needs in the database.

You may realize that we didn't add an application to the project, but just ran syncdb. First, this will allow South to be installed at the beginning. With South, all the migration work in our application can be completed, including initial migration.

Since we have just completed many changes, it will be a good time to submit them. You have to adapt to frequent submissions. you must know that the smaller the submission granularity, the higher the degree of freedom to roll back when an error occurs.

To submit, let's see all the modifications.

(Git)

$ git status# On branch master# Changes not staged for commit:#  (use "git add 
 
  ..." to update what will 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 will be committed)##    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 some files that you never want to submit, such as the. pyc file after python compilation and the. swp file of vim. Ignore these files, create a. gitignore or. hgignore file in the project root directory, and add the shell mode that matches the file you do not want to trace. For example, most of my files are:
?

The code is as follows:

*. Pyc. * swp

Before submitting the package, you need to check the Python package we have installed. We hope to track the name and version of the Python package we use, so that we can easily recreate the production environment. Pip has a command to meet our needs.

$ pip freeze > requirements.txt

I saved the pip output to a file named requirements.txt and added the file to code control. In this way, we always have an updated list containing the packages to be used.

Now add settings. py and requirements.txt to The submit 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, so they can "write" it ". A common way to set. py is to move from a strange project folder to a new folder called conf or config. You need to make some small changes to manage. py to adapt to this movement.

In setting. py, INSTALLED_APPS will soon become a bunch of third-party packages, including django applications and project-specific applications. I used to divide INSTALLED_APPS into three categories:

1. DEFAULT_APPS: A Django framework application that is used as part of the default Django installation (such as admin)
2. THIRD_PARTY_APPS: Like South
3. LOCAL_APPS: the application you created

This makes it easier to see which third-party applications are used and which are the project's own. Remember that the last line of code is similar to the following:

INSTALLED_APPS = DEFAULT_APPS + THIRD_PARTY_APPS + LOCAL_APPS

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

Create an application

Create an application (python manage. py startapp myapp) using manage. py in normal mode and add it to INSTALLED_APP. At the same time, it takes time to make manage. py executable (chmod + x manage. py), so that you can simply enter./manage. pyInstead of always Entering python manage. py. To be honest, few developers do this. I cannot figure out why.

Before adding a model, the first thing we need to do is to tell South that we want to use it for migration:

$ python manage.py schemamigration myapp --initial

This will create a portable file to apply the changes to the database model (if any) without the need to completely destroy it and then recreate it. It can also be used to restore changes when conditions deviate. Run the following command to Port database changes (even if no changes have been made:

$ python manage.py migrate myapp

South is smart enough to know where to find the transplant file, and remember the last transplant. You can specify a separate transplant file, but this is generally not 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 will detect models in myapp and automatically add, delete, or modify tables in the database. Then, use the above Port command to apply the changes to the database.

Development area

Note that the development area is separated from the file that you have confirmed for obvious reasons. Using Git and Mercurial is simple and helpful for deployment. Create a directory outside the directory where django_project is located as your development region (I call it dev ).

In your development Directory, use git or Mercurial to clone the current project:

$ (git/hg) clone /path/to/my/project/

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

Because it is easy to use Git and Mercurial for branches, you can create branches when you switch between new branches or sites in large scale. The following are the implementation methods of the two tools:
(Git)

$ git checkout -b 
 

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

$ hg branch 
 

Note that branch is a controversial topic in the Mercurial community. Currently, there are some available options, but none of them are "obviously correct. Here, I use named branches, which may be the safest and most beneficial branch style. Any submission after branch command will take effect in the new branch.

Deploy with Fabric

Then we have a Django application. How can we deploy it? Fabric. Discussing anything else is a waste of time for a project of a reasonable size. Fabric can be used for many different purposes, but it is indeed outstanding in terms of deployment.

$ pip install fabric

Fabric requires a fabfile named fabfile. py, which defines all the actions we can use. Now let's create it. Write the following content to fabfile. py and put it to the root directory of the project.

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 submit your changes, but the submission only takes place when the test passes. In this case, a simple "pull" action in the production environment can be actually deployed. We will add more things to the actual deployment. Add the following content to fabfile. py:

Current 1/2 page12 Next page