Suggestions on Python Django framework deployment

This article mainly introduces some suggestions for deploying the Python Django framework, including the layout of project files, for more information, see "what is the optimal layout of Django applications, configuration files, and other related directories?"

Some friends always ask us this question, so I want to spend some time writing about how we really think about it, so that we can easily let others take part in this document. Note that this is based on Django 1.7.1, but it can be easily applied to any version after Django 1.4.

Although Django 1.4 was released with an improved project layout (which took a long time), this article provides some suggestions for optimizing the project layout.
Why is this layout better?

The recommended project layout here has the following advantages:

1. This allows you to obtain, repackage, and reuse a single Django application for other projects. This is usually not clear, just as you are building an application whether or not to reuse it. Building an application in a way that you want to reuse at the beginning makes it easier.
2. Encourage the design of reusable applications.
3. Detailed environment settings. In a single configuration file, if DEBUG = True is meaningless. This makes it easy to see which configurations are shared and which can be overwritten on the basis of each environment.
4. PIP requirements ).
5. If necessary, project-level templates and static files can override application-level default values.
6. Small and more specific test files are easier to read and understand.

Suppose you have two application blogs and users, and two development environments dev and prod. The layout structure of your project should be as follows:

The code is as follows:

Myproject/
Manage. py
Myproject/
_ Init _. py
Urls. py
Wsgi. py
Settings/
_ Init _. py
Base. py
Dev. py
Prod. py
Blog/
_ Init _. py
Models. py
Managers. py
Views. py
Urls. py
Templates/
Blog/
Base.html
List.html
Detail.html
Static/
...
Tests/
_ Init _. py
Test_models.py
Test_managers.py
Test_views.py
Users/
_ Init _. py
Models. py
Views. py
Urls. py
Templates/
Users/
Base.html
List.html
Detail.html
Static/
...
Tests/
_ Init _. py
Test_models.py
Test_views.py
Static/
Css/
...
Js/
...
Templates/
Base.html
Index.html
Requirements/
Base.txt
Dev.txt
Test.txt
Prod.txt

The rest of this article describes how to migrate a project to this layout, and why this layout is better.
Current default layout

We will call the example project foo. I know this is a very creative name. Let's assume that here we will start foo.com. But when we want to map our project name to the final domain name, this project will exist here in a way that is not required in any sense.

If you open this project using the django-admin.py startproject foo command, you will get a directory structure like this:

foo/  manage.py  foo/    __init__.py    settings.py    urls.py    wsgi.py

This layout is a good starting point. we have a top-level directory foo, which contains the manage. py file and the project directory foo /. In this directory, you can query the Source Code Control System (such as Git ).

You should think of the sub-directory foo/as the project. All the files here are not a Django application, but project-related supporting files.
Modify configurations

The task here is to correct the bad configuration file. I show this layout to new users, and I am often surprised how these people know that this is even possible. As a matter of fact, when everyone knows that these configurations are only Python code, they do not regard them as Python code.

Therefore, let's improve the configuration. For oo projects, there will be four development environments: dev, stage, jenkins, and production. Create a configuration file for each development environment. What to do in this process is:

Create a configuration directory under the foo/directory and create an empty _ init _. py file.
Move foo/settings. py and rename it foo/settings/base. py.
Create separate dev. py, stage. py, jenkins. py, and production. py files under the foo/settings/directory. The specific configuration files of these four environments should contain the following content:

  from base import *

Why is this important? For local development, you want to set DEBUG = True, but it is easy to accidentally push this to the production Code. Therefore, you need to enable foo/settings/production. py file, add DEBUG = False after initial base import. Now, for this stupid mistake, your production environment is safe.

What else can be customized? Obviously, you can configure development environments such as staging, jenkins, and production for different databases or even different hosts. Then adjust those configurations in each environment configuration file.
Use these configurations

No matter which method you usually use, using these configurations is very simple. To use the operating system environment, you only need:

export DJANGO_SETTINGS_MODULE=“foo.settings.jenkins”

Now you are using the jenkins configuration.

Alternatively, you may prefer to use them as such command line options:

./manage.py migrate —settings=foo.settings.production

Similarly, if you use gunicorn, the command is as follows:

gunicorn -w 4 -b 127.0.0.1:8001 —settings=foo.settings.dev

What other customizable configurations are available?

Another practical suggestion is to change some default set configurations from tuples to lists. For example, INSTALLED_APPS:

INSTALLED_APPS =（...）

Changed:

INSTALLED_APPS = [  …]

Now, based on specific configuration files in each environment, we can easily add and delete applications in the foo/settings/base. py file. For example, you may only want to install the Django debugging toolbar in the dev environment rather than in other environments.

This technique is also useful for TEMPLATE_DIRS and MIDDLEWARE_CLASSES configuration.

Another technique we often use is to divide an application into two lists. one is a prerequisite for a project, and the other is used for actual project applications. As shown below:

PREREQ_APPS = [  ‘django.contrib.auth',  ‘django.contrib.contenttypes',  …  ‘debug_toolbar',  ‘imagekit',  ‘haystack',] PROJECT_APPS = [  ‘homepage',  ‘users',  ‘blog',] INSTALLED_APPS = PREREQ_APPS + PROJECT_APPS

Why is this useful? First, it helps to better distinguish Django core applications, third-party applications, and specific applications of your own internal projects. Specifying the PROJECT_APPS list of your specific application often comes in handy for testing and code coverage. You have written an application list, so you can easily and automatically ensure that their test runs. the recorded test coverage only includes them, not any third-party applications, you do not need to maintain this list in two different places.
Modification requirements

The project has a requirements.txt file. it is installed using the following command:

pip install -r requirements.txt

A little-known feature of the requirements.txt file is that you can use the-r parameter to include other files. For this reason, we can create a base.txt file for all installation requirements. if we need to be able to run the test, we can create a specific requirements/test.txt file containing the following content:

The code is as follows:

-R base.txt
Pytest = 2.5.2
Coverage = 3.7.1

I admit that this is not a huge benefit, but it does help distinguish what is the requirement of every development environment. At the same time, for its performance, it will not install a bunch of things that are not useful in actual production, to reduce the pip installation time in the production environment.
Test File

Why do we need to split a large test file? One of the main reasons is that if you write enough tests to each application in a tests. py file, the file will eventually become very bloated. This code is poorly readable and you have to spend a lot of time in the editor to scroll through the code.

When you work with other developers, small files can also minimize conflicts during code merging. Small files are your friends.
URLs

For small projects, put all URL definitions in the foo/urls. py file so that they are in the same place. However, if your goal is code clarity and reusability, you 'd better define their URLs in each application and include them in your main project. You should not do the following:

urlpatterns = patterns(‘',  url(r'^$', HomePageView.as_view(), name=‘home'),  url(r'^blog/$', BlogList.as_view(), name=‘blog_list'),  url(r'^blog/(?P
 
  d+)/$', BlogDetail.as_view(), name=‘blog_detail'),  …  url(r'^user/list/$', UserList.as_view(), name=‘user_list'),  url(r'^user/(?P
  
   w+)/$', UserDetail.as_view(), name=‘user_detail'),)
  
 

You should do this:

urlpatterns = patterns(‘',  url(r'^$', HomePageView.as_view(), name=‘home'),  url(r'^blog/‘, include(‘blog.urls')),  url(r'^user/‘, include(‘user.urls')),)

Templates and static resources

Each application has templates/and static/directories, which allows an application to be reused in other projects.

For a cool feature, we get all the default templates and any related static resources provided by the application in a package, such as special Javascript.

However, it also allows us to override templates under the foo/templates/directory of each project's main directory. We have added a templates/blog/detail.html template to overwrite the default blog/templates/blog/detail.html template.
Reuse Django applications

Assuming that you have used this layout for a while, one day you will realize that your new project requires a blog application, and the application from your foo project will be perfect. So you copy and paste files ...... Error! Now you have two copies of this application. Assume that you still remember to manually migrate between projects to fix bugs and add new features in a copy.

Instead, create a new directory for your blog and put the contents in the foo/blog/directory. At the same time, adjust the existing foo project and your new project for installation.

If needed, they can still track the two different versions of the application, or continue to update, and get all of their evolving bug fixes and new features. You can still override templates and static resources based on each project as needed, so there is no problem in doing so.