Django Geliştiricilerinin Yaptığı En Önemli 10 Hata

Bu eğitimde, Django geliştiricileri tarafından sıklıkla yapılan bazı yaygın hatalara ve bunlardan kaçınmanın yollarına bakacağız. Bu öğretici, yetenekli bir Django geliştiricisi olsanız bile yararlıdır, çünkü yönetilemeyecek kadar büyük ayarları sürdürmek veya statik varlıklardaki çakışmaları adlandırmak gibi hatalar, yalnızca Django'da ilk denemelerini yapan yeni geliştiricilerle sınırlı değildir.

Django, yaygın geliştirme zorluklarını yararlı bir şekilde çözen ve esnek, iyi yapılandırılmış uygulamalar oluşturmanıza olanak tanıyan ücretsiz ve açık kaynaklı bir Python web çerçevesidir. Django, kutudan çıktığı gibi birçok modern özelliğe sahiptir. Şahsen benim için Yönetici, Nesne İlişkisel Eşleme aracı (ORM), Yönlendirme ve Şablonlama özellikleri Django'yu ilk tercihim yaptı çünkü uygulamalar çok fazla iş gerektiriyor ve işimden herhangi bir geliştirici kadar zevk alırken, harcamak istiyorum. bu temel tekrarlayan görevlere mümkün olduğunca az zaman ayırın. Django, tüm bunları esneklikten ödün vermeden yapmanızı sağlar.

Django'nun öldürücü özelliği, modellerinizin şema ve yönetici paneli modellerinden otomatik olarak (otomatik olarak?) oluşturulan ve sizi bir sihirbaz gibi hissettiren, yapılandırılabilir güçlü bir yönetici arayüzüdür. Yönetici arayüzü aracılığıyla bir kullanıcı, erişim kontrol listesi (ACL), satır düzeyinde izinler ve eylemler, filtreler, siparişler, widget'lar, formlar, ekstra URL yardımcıları ve hayal edebileceğiniz her şey dahil olmak üzere birçok şeyi yapılandırabilir. Her uygulamanın bir yönetici paneli gerektirdiğine inanıyorum - henüz değilse, temel uygulamanızın bir taneye ihtiyacı olana kadar bu sadece bir zaman meselesi. Django admin ile hızlı ve esnek bir şekilde bir tane oluşturabilirsiniz.

Django, kutudan çıktığı gibi tüm büyük veritabanlarıyla çalışan güçlü bir ORM'ye sahiptir. Tembel olduğu için diğer ORM'lerin aksine veritabanınıza yalnızca ihtiyacınız olduğunda ulaşır. Python kaynak kodunuzdan kullanabileceğiniz tüm temel SQL talimatlarını (ve işlevlerini) destekler ve Python'un özellikleri nedeniyle çok rahat hissettirir.

Django'nun şablonlama motoru aynı zamanda çok esnek ve güçlüdür. Birçok standart filtre ve etiket kullanabilir, projeniz için yeni özel filtrelerinizi ve etiketlerinizi oluşturabilirsiniz. Django, Django şablonlarının yanı sıra diğer şablon motorlarını da destekler ve şablon işleme için standart kısayol işlevleri aracılığıyla diğer şablon motorlarının kolay entegrasyonu için bir API sağlar.

Django, gelen istekleri ayrıştırabilen ve bir yönlendirici şemasından yeni URL'ler oluşturabilen bir URL yönlendiricisi gibi birçok başka büyük özelliğe sahiptir. Bir bütün olarak, Django çerçevesi hoş bir deneyimdir ve ne zaman yardıma ihtiyacınız olursa, belgeleri okumanız yeterlidir.

Hata No. 1: Proje Bağımlılıkları için Global Sistem Python Ortamını Kullanma

Bağımlılık çakışmaları üretebileceğinden proje bağımlılıkları için Python'un küresel ortamını kullanmayın. Python aynı anda birden fazla paket sürümünü kullanamaz. Farklı projeler aynı paketin farklı uyumsuz sürümlerini gerektiriyorsa bu sorun olabilir.

Bu hata genellikle Python'un ortam izolasyon özelliklerini bilmeyen yeni Python ve Django geliştiricileri tarafından yapılır.

Ortamınızı izole etmenin birçok yolu vardır, ancak en yaygın yollar şunlardır:

• virtualenv: Bir Python ortam klasörü oluşturan ve ortamı etkinleştirmek ve ortamdaki kurulu Python paketlerini yönetmek için komut dosyaları içeren bir Python paketi. Bu benim favori yöntemim çünkü işi yapmanın en basit yolu bu. Genelde proje klasörüne yakın bir ortam yaratırım.
• virtualenvwrapper: Global olarak yüklenen ve oluşturma/silme/etkinleştirme/vb. için bir araç seti sağlayan bir Python paketi. sanal ortamlar. Tüm sanal ortamlar tek bir klasörde depolanır (WORKON_HOME ortam değişkeni aracılığıyla geçersiz kılınabilir). virtualenvwrapper yerine virtualenv kullanmanın herhangi bir avantajı görmüyorum.
• Sanal Makineler (VM): Uygulamanıza ayrılmış tüm bir sanal makineden daha büyük bir izolasyon yoktur. Aralarından seçim yapabileceğiniz çok sayıda araç var; VirtualBox (ücretsiz), VMware, Parallels ve Proxmox (kişisel favorim ve ücretsiz bir sürümü var). Vagrant gibi bir VM otomasyon aracıyla birlikte bu, son derece güçlü bir çözüm olabilir.
• Konteynerler: Son birkaç yıldır Docker'ı hemen hemen her projede, özellikle de sıfırdan başladığım her yeni projede kullanıyorum. Docker, birçok özellik sağlayan ve konteyner otomasyonu için birçok üçüncü taraf aracına sahip harika bir araçtır. Kapsayıcılarınızı son derece hızlı bir şekilde yeniden oluşturmayı sağlayan bir katman önbelleğe alma özelliğine sahiptir. Kapsayıcılarda, küresel sistem Python ortamını kullanıyorum, çünkü her kapsayıcının kendi dosya sistemi vardır ve projeler yüksek düzeyde yalıtılmıştır. Docker, özellikle Docker deneyimi varsa, yeni ekip üyelerinin proje üzerinde daha hızlı çalışmaya başlamasına olanak tanır.

Bana sorarsanız proje bağımlılığı izolasyonu ve yönetimi için virtualenv Python paketini ve Docker kapsayıcılarını tercih ederim.

Hata No. 2: Bir requirements.txt Dosyasında Proje Bağımlılıklarını Sabitlememek

Her yeni Python projesi, bir gereksinim.txt dosyası ve yeni bir yalıtılmış ortam ile başlamalıdır. Normalde tüm paketleri pip/easy_install aracılığıyla kurarsınız ancak bunları requirements.txt dosyanıza da eklemeyi asla unutmayın. Bu, projenizi sunuculara yerleştirmeyi veya bir ekip üyesinin projeyi kendi makinesinde başlatmasını kolaylaştırır (daha uygun olması mümkün olur).

Ek olarak, bağımlılıklarınızın belirli sürümünü requirements.txt dosyanıza sabitlemek de aynı derecede önemlidir. Genellikle, bir paketin farklı sürümleri farklı modüller, işlevler ve işlev parametreleri sağlar; bağımlılıktaki küçük bir sürüm değişikliği bile paketinizi bozabilir. Projeniz yayındaysa ve sürüm oluşturma olmadan derleme sisteminiz her zaman paketin mevcut en son sürümünü yükleyeceğinden düzenli olarak planlanmış dağıtımlarınız varsa bu çok ciddi bir sorundur.

Paketlerinizi daima üretim için sabitleyin! Şahsen, bunu yapmama yardımcı olan pip-tools adlı çok güzel bir araç kullanıyorum. Bağımlılıklarınızı yönetmenize yardımcı olan bir dizi komut satırı aracı sağlar. Yalnızca bağımlılıklarınızı değil, bağımlılıklarınızın bağımlılıklarını içeren tüm bağımlılık ağacınızı sabitleyen bir requirements.txt dosyasını otomatik olarak oluşturur.

Bazen, bağımlılıklar listenizden yalnızca bazı paketleri güncellemek istersiniz (örneğin, yalnızca Django/Flask/herhangi bir çerçeve veya yardımcı program), "pip dondurma" kullandıysanız, hangi bağımlılıkların hangi paketler için olduğunu bilemezsiniz ve bu nedenle bir bağımlılığı yükseltemezsiniz. Ancak pip araçlarıyla, hangi bağımlılığa bağladığınıza bağlı olarak paketleri otomatik olarak sabitler, böylece hangi paketlerin güncellenmesi gerektiğini otomatik olarak çözer. Bonus olarak, requirements.txt dosyasındaki yorumlarla nasıl işaretlediği nedeniyle, hangi paketin hangi bağımlılıktan geldiğini de tam olarak bilirsiniz.

Daha dikkatli olmak için, bağımlılık kaynak dosyalarınızı da yedeklemek iyi bir fikirdir! Dosya sisteminizde, Git tarafından yönetilen bir klasörde, S3 klasöründe, FTP'de, SFTP'de bir kopyasını saklayın, ancak elinizin altında bulundurun. Listelenmemiş nispeten küçük bir paketin npm'de çok sayıda paketi bozduğu durumlar olmuştur. Pip, gerekli tüm bağımlılıkları kaynak dosyalar olarak indirmek için yardımcı bir araç sağlar, pip help download çalıştırarak daha fazlasını okuyun.

Hata No. 3: Sınıf Tabanlı Görünümler Yerine Eski Stil Python İşlevlerini Kullanma

Bazen, özellikle testler veya yardımcı program görünümleri için bir uygulamanın views.py dosyasında küçük bir Python işlevi kullanmak iyi bir fikirdir, ancak genellikle uygulamalarınızda sınıf tabanlı görünümler (CBV'ler) kullanmalısınız.

CBV'ler, profesyoneller tarafından oluşturulan ve tüm ortak davranışları kapsayan ortak web geliştirme görevlerini uygulayan soyut sınıflar sağlayan genel görünümlerdir. Harika bir yapılandırılmış API'leri var ve CBV'leri kullandığınızda nesne yönelimli programlamanın tüm avantajlarını kullanabilirsiniz. Kaynak kodunuzu daha net ve okunabilir hale getirir. Listeler, CRUD işlemleri, form işleme vb. için Django standart görünüm işlevlerini kullanmanın acısını unutun. Yalnızca görünümünüz için uygun CBV'yi genişletin ve sınıf özelliklerini veya işlevlerini geçersiz kılın (genellikle bir işlev bir özellik döndürür ve oraya herhangi bir mantık ekleyebilirsiniz. görünüm davranışını yapılandıran CBV'ler yerine görüntüleme işlevlerini kullanmanız durumunda kaynak kodunuzdan spagetti yapar.

Örneğin, projenizde görünüm bağlamları oluşturmak, satır düzeyinde yetkilendirmeyi kontrol etmek, uygulama yapınızdan şablon yollarını otomatik olarak oluşturmak, akıllı önbelleğe almayı entegre etmek ve daha fazlası için temel CBV davranışlarını geçersiz kılan farklı karışımlar olabilir.

Görünümleriniz için şablon adlarını bir uygulama adına ve bir görünüm sınıfı adına göre standartlaştıran Django Şablon Adları adlı paketi oluşturdum. Her gün kullanıyorum ve isim bulmak için çok zaman kazandırıyor. Karışımı CBV'nize koymanız yeterlidir— class Detail(TemplateNames, DetailView): — ve çalışmaya başlayacaktır! Elbette, işlevlerimi geçersiz kılabilir ve mobil duyarlı şablonlar, kullanıcı aracıları için farklı şablonlar veya istediğiniz herhangi bir şeyi ekleyebilirsiniz.

4 Numaralı Hata: Şişman Görünümler ve Zayıf Modeller Yazmak

Uygulama mantığınızı modeller yerine görünümlere yazmanız, modelinize ait kodu görünüme yazdığınız anlamına gelir, bu da onu "şişman" ve modelinizi "sıska" yapar.

Şişman modeller, sıska görüşler yazmalısın.

Modellerinizde mantığı küçük yöntemlere ayırın. Bu, tonlarca kodu kopyalayıp yapıştırmak yerine birkaç kod satırında birden çok kaynaktan (yönetici arabirimi kullanıcı arabirimi, ön uç kullanıcı arabirimi, API uç noktaları, birden çok görünüm) birden çok kez kullanmanıza olanak tanır. Bu nedenle, bir dahaki sefere bir kullanıcıya e-posta gönderirken, denetleyicinize bu mantığı yazmak yerine modeli bir e-posta işleviyle genişletin.

Bu ayrıca, e-posta mantığını, bunun gerçekleştiği her denetleyicide tekrar tekrar test etmek yerine tek bir yerde test edebileceğiniz için kodunuzun birim testini kolaylaştırır.

Sorun hakkında daha fazla bilgiyi Django En İyi Uygulamalar projesinde okuyabilirsiniz. Çözüm basit: Şişman modeller ve sıska görünümler yazın, bu yüzden bir sonraki projenizde yapalım (veya mevcut projenizi yeniden değerlendirelim).

5 Numaralı Hata: Devasa, Yönetilemez Bir Ayarlar Dosyası

Yeni Django proje ayarları dosyası bile birçok ayara sahiptir. Gerçek bir projede, bir ayar dosyası 700'den fazla yapılandırma satırına kadar büyür ve özellikle geliştirme, üretim ve hazırlama ortamlarınızın tümü özel yapılandırmalara ihtiyaç duyduğunda bakımı zorlaşacaktır.

Konfigürasyon dosyasını manuel olarak bölebilir ve özel yükleyiciler oluşturabilirsiniz, ancak sizi, birlikte yazdığım güzel ve iyi test edilmiş bir Python paketi olan Django Split Settings ile tanıştırmak istiyorum.

Paket, yollar için joker karakterleri destekleyen ve yapılandırma dosyalarınızı aynı bağlamda içe aktaran, optional ve include olmak üzere iki işlev sağlar; bu, önceden yüklenmiş dosyalarda belirtilen yapılandırma girişlerini kullanarak yapılandırmanızı oluşturmayı kolaylaştırır. Django performansını etkilemez ve herhangi bir projede kullanabilirsiniz.

Minimum yapılandırma örneğine göz atın:

 from split_settings.tools import optional, include include( 'components/base.py', 'components/database.py', 'components/*.py', # the project different envs settings optional('envs/devel/*.py'), optional('envs/production/*.py'), optional('envs/staging/*.py'), # for any local settings optional('local_settings.py'), )

6 Numaralı Hata: Hepsi Bir Arada Uygulama, Kötü Uygulama Yapısı ve Yanlış Kaynak Yerleşimi

Herhangi bir Django projesi birden çok uygulamadan oluşur. Django notasyonunda bir uygulama, en az __init__.py ve models.py dosyalarını içeren bir Python paketidir; En son Django sürümlerinde, models.py artık gerekli değildir. __init__.py yeterlidir.

Django uygulamaları Python modülleri, Django'ya özgü modüller (görünümler, URL'ler, modeller, yönetici, formlar, şablon etiketleri vb.), statik dosyalar, şablonlar, veritabanı geçişleri, yönetim komutları, birim testleri ve daha fazlasını içerebilir. Monolit uygulamalarınızı basit mantık kullanarak küçük, yeniden kullanılabilir uygulamalara bölmelisiniz. Uygulamanın tüm amacını bir veya iki kısa cümleyle tanımlayabilmelisiniz. Örneğin: "Kullanıcıların hesaplarını e-posta ile kaydetmelerine ve etkinleştirmelerine olanak tanır."

Proje klasörü project çağırmak ve uygulamaları project/apps/ içine yerleştirmek iyi bir fikirdir. Ardından, tüm uygulama bağımlılıklarını kendi alt klasörlerine yerleştirin.

Örnekler:

• Statik dosyalar: project/apps/appname/static/appname/
• Şablon etiketleri: project/apps/appname/templatetags/appname.py
• Şablon dosyaları: project/apps/appname/templates/appname/

Tüm statik klasörler tek bir klasörde birleştirildiğinden ve iki veya daha fazla uygulamanın bir js/core.js dosyası varsa, settings.INSTALLED_APPLICATIONS içindeki son uygulama öncekileri geçersiz kılacağından, alt klasörlerde her zaman uygulama adının önüne ekleyin. Bir keresinde şu anki projemde bu hatayı yaşadım ve ekip özel bir SPA yönetici paneli uyguladığı ve dosyalarını aynı şekilde adlandırdığı için başka bir geliştiricinin static/admin/js/core.js geçersiz kıldığını fark edene kadar yaklaşık altı saat hata ayıklama kaybettim.

İşte çok sayıda kaynak ve Python modülü içeren bir portal uygulaması için örnek yapı.

 root@c5b96c395cfb:/test# tree project/apps/portal/ project/apps/portal/ ├── __init__.py ├── admin.py ├── apps.py ├── management │ ├── __init__.py │ └── commands │ ├── __init__.py │ └── update_portal_feeds.py ├── migrations │ └── __init__.py ├── models.py ├── static │ └── portal │ ├── css │ ├── img │ └── js ├── templates │ └── portal │ └── index.html ├── templatetags │ ├── __init__.py │ └── portal.py ├── tests.py ├── urls.py └── views.py 11 directories, 14 files

Böyle bir yapıyı kullanarak, uygulamayı herhangi bir anda başka bir Python paketine aktarabilir ve tekrar kullanabilirsiniz. Hatta açık kaynak paketi olarak PyPi'de yayınlayabilir veya başka bir klasöre taşıyabilirsiniz.

Bunun gibi bir proje yapısı elde edeceksiniz:

 root@c5b96c395cfb:/test# tree -L 3 . ├── deploy │ ├── chef │ └── docker │ ├── devel │ └── production ├── docs ├── logs ├── manage.py ├── media ├── project │ ├── __init__.py │ ├── apps │ │ ├── auth │ │ ├── blog │ │ ├── faq │ │ ├── pages │ │ ├── portal │ │ └── users │ ├── conf │ ├── settings.py │ ├── static │ ├── templates │ ├── urls.py │ └── wsgi.py └── static └── admin ├── css ├── fonts ├── img └── js 25 directories, 5 files

Gerçek bir projede elbette daha karmaşık olacaktır, ancak bu yapı işleri daha basit ve temiz hale getirir.

7 No'lu Hata: STATICFILES_DIRS ve STATIC_ROOT Acemi Django Geliştiricilerini Karıştırıyor

Statik dosyalar, uygulamanın kullanımı yoluyla değişmeyen varlıklardır, örneğin JavaScript, CSS, resimler, yazı tipleri vb. Django'da, dağıtım işlemi sırasında yalnızca genel bir dizine “toplanır”.

Geliştirme modunda — python manage.py runserver — Django, STATICFILES_FINDERS ayarını kullanarak statik dosyaları arar. Varsayılan olarak, istenen statik dosyayı STATICFILES_DIRS ayarında listelenen klasörlerde bulmaya çalışır. Başarısızlık durumunda, Django, projede kurulu her uygulamanın static klasörüne bakan django.contrib.staticfiles.finders.AppDirectoriesFinder kullanarak dosyayı bulmaya çalışır. Bu, kendi statik dosyalarıyla birlikte gönderilen yeniden kullanılabilir uygulamaları yazmanıza olanak tanır.

Üretimde, statikinizi Nginx gibi bağımsız bir web sunucusu kullanarak sunarsınız. Web sunucusu, Django proje uygulamalarının yapısı veya statik dosyalarınızın hangi klasörlerde dağıtıldığı hakkında hiçbir şey bilmez. Neyse ki, Django size STATICFILES_FINDERS içinde yürüyen ve tüm statik dosyaları static uygulamalardan kopyalayan python manage.py collectstatic Manage.py Collectstatic statik yönetim komutunu sağlar. STATICFILES_DIRS içinde listelenen klasör ve klasörleri STATIC_ROOT ayarında belirttiğiniz dizine atın. Bu, Django geliştirme modu sunucusuyla aynı mantığı kullanarak statik dosya kaynaklarının çözümlenmesine izin verir ve web sunucunuz için tüm statik dosyaları tek bir yerde toplar.

Üretim ortamınızda collectstatic çalıştırmayı unutmayın!

Hata No. 8: Varsayılan STATICFILES_STORAGE , Üretimde Django Şablonları Yükleyicileri

STATICFILES_STORAGE

Biraz da üretim ortamı varlık yönetiminden bahsedelim. "Varlıklar asla sona ermez" politikasını kullanırsak en iyi kullanıcı deneyimini sağlayabiliriz (bunun hakkında daha fazla bilgiyi buradan okuyabilirsiniz). Bu, tüm statik dosyalarımızın web tarayıcıları tarafından haftalar, aylar ve hatta yıllar boyunca önbelleğe alınması gerektiği anlamına gelir. Başka bir deyişle, kullanıcılarınız varlıklarınızı yalnızca bir kez indirmelidir!

Bu harika ve bunu statik dosyalar klasörümüz için Nginx yapılandırmasında birkaç satırla yapabiliriz, peki ya önbellek geçersiz kılma? Kullanıcı varlıklarımızı yalnızca bir kez indirecekse, bir menüdeki bir öğe için logonuzu, yazı tiplerini, JavaScript'i veya metin rengini güncellerseniz ne olur? Bunu atlamak için, her dağıtımda statik dosyalarımız için benzersiz URL'ler ve dosya adları oluşturmalısınız!

Bunu basitçe ManifestStaticFilesStorage'ı STATICFILES_STORAGE olarak kullanarak (dikkatli olun, karma yalnızca DEBUG=false modunda etkinleştirilir) ve yukarıda açıklanan collectstatic yönetim komutunu çalıştırarak yapabiliriz. Bu, üretim web sitenize varlık isteklerinin sayısını azaltacak ve web sitenizin çok daha hızlı oluşturulmasını sağlayacaktır.

Önbelleğe Alınmış Django Şablon Yükleyici

Bir başka harika Django özelliği, her şablon oluşturma işleminde şablon dosyalarını yeniden yüklemeyen ve ayrıştırmayan önbelleğe alınmış şablon yükleyicidir. Şablon ayrıştırma çok pahalı bir işlemdir ve çok fazla kaynak kullanır. Varsayılan olarak, Django şablonları her istekte ayrıştırılır, ancak bu, özellikle kısa sürede binlerce isteği işleyebileceğiniz üretim sırasında kötüdür.

İyi bir örnek ve bunun nasıl yapılacağına ilişkin ayrıntılar için cached.Loader yapılandırma bölümüne bakın. Dosya sisteminden ayrıştırılmış şablonları yeniden yüklemediği için yükleyiciyi geliştirme modunda kullanmayın; her şablon değişikliğinde python manage.py startapp kullanarak projenizi yeniden başlatmanız gerekecek. Bu, geliştirme sırasında can sıkıcı olabilir, ancak üretim ortamı için mükemmeldir.

Hata No. 9: Yardımcı Programlar veya Komut Dosyaları için Saf Python Komut Dosyaları

Django, Yönetim Komutları adı verilen çok güzel bir özellik sunar. Proje araçlarınız için tekerlekleri yeniden icat etmek ve ham Python betikleri yazmak yerine onu kullanın.

Ayrıca, Django için özel uzantıların bir koleksiyonu olan Django Uzantıları paketine göz atın. Belki birisi komutlarınızı zaten uygulamıştır! Halihazırda pek çok ortak görev komutu vardır.

10 Numaralı Hata: Tekerleği Yeniden Keşfetmek

Django ve Python'un binlerce kullanıma hazır çözümü var. Benzersiz olmayan bir şey yazmadan önce Google'ı deneyin; muhtemelen zaten var olan zengin özelliklere sahip bir çözüm vardır.

Sadece işleri basitleştirmeye çalışın. Önce Google! Kaliteli bir paket bulursanız kurun, yapılandırın, genişletin ve projenize entegre edin ve tabii ki fırsatınız olduğunda açık kaynağa katkıda bulunun.

Başlangıç ​​olarak, Django için kendi genel paketlerimin listesi:

• Django Makroları URL'si, makroları kullanarak Django uygulamalarınızda URL kalıpları yazmayı (ve okumayı) kolaylaştırır.
• Django Templates Names, CBV şablon adlarınızı kolayca standartlaştırmanıza olanak tanıyan küçük bir karışımdır.
• Django-split-settings, Django ayarlarını birden çok dosya ve dizinde düzenlemenizi sağlar. Ayarları kolayca geçersiz kılın ve değiştirin. Ayarlar dosya yollarında joker karakterler kullanın ve ayar dosyalarını isteğe bağlı olarak işaretleyin.

Kendinizi Tekrar Etmeyin (KURU)!

DRY metodolojisini gerçekten seviyorum; bu yüzden Django iskeletini kutudan çıktığı gibi gerçekten güzel özelliklere sahip bir kolaylık aracı olarak yarattım:

• Geliştirme/üretim için docker-compose tarafından yönetilen, bir konteyner listesini kolayca düzenlemenizi sağlayan Docker görüntüleri.
• Üretim dağıtımı için basit Fabric betiği.
• Temel ve yerel kaynaklar için ayarlarla Django Bölünmüş Ayarlar paketi için yapılandırma.
• Projeye entegre web paketi - collectstatic komutunda Django tarafından yalnızca dist klasörü toplanacaktır.
• Üretimdeki önbelleğe alınabilir Django şablonları, karma statik dosyalar, entegre hata ayıklama araç çubuğu, günlük kaydı vb. gibi tüm temel Django ayarlarını ve özelliklerini yapılandırdı.

Bir sonraki projeniz için sıfırdan kullanıma hazır bir Django Skeleton'dur ve umarım projenizi önyükleyerek size çok zaman kazandıracaktır. Web paketinin minimum temel yapılandırması vardır, ancak aynı zamanda .scss dosyalarını işlemek için önceden yapılandırılmış SASS kurulumuna sahiptir.