- Ayar otomasyonu için bildirim formatları kullanır, projeye katılan yeni geliştiriciler için zaman ve maliyeti aza indirmek için.
- Yürütme ortamları arasında maksimum taşınabilirlik sunan temel işletim sistemi ile clean contract vardır.
- Modern bulut platformları üzerindeki dağıtım için uygun, sunucu ve sistem yönetimi ihtiyacını ortadan kaldırır.
- Maksimum çeviklik için sürekli dağıtım sağlayan geliştirme ve üretim arasındaki ayrışmayı en aza indirir,
- Ve önemli değişiklikler dışında, mimari ve geliştirici uygulamaları düzeyinde ölçeklendirilebilir.
Bu belgeye katkı veren kişiler doğrudan ilgili geliştiriciler, yüzlerce uygulama geliştirmiş, tanıklık etmiş ve heroku platformun da çalışmalarda geliştirme yapmıştır. Bu döküman, katkıcıların deneyim ve gözlemlerini sentezler. Katkıcıların amacı modern yazılım geliştirmede gördükleri sorunların bilincini arttırmak, sorunları tartışıp ortak ve kavramsal bir çözüm sağlamaktır.
Herhangi bir çalışan uygulama geliştiren mühendisler okumalıdır.
12 FAKTÖR
1) Codebase(Kod Tabanı)Bir codebase bir çok uygulamanın sürüm kontrolünü incelemektedir. 12 faktör uygulaması her zaman sürüm kontrol sisteminde izlenir, Git , Mermcurial, Subversion gibi. Sürüm takip, kod tabanının bir kopyası, kod deposu olarak bilinir. Bir codebase herhangi tek bir depo(Subverison) ya da kökü paylaşan bir dizi depodur(Git).
Codebase ile uygulama arasında bire bir ilişki her zaman vardır:
Birden fazla codebase varsa bu bir uygulama değil dağıtık sistemdir. Dağıtık sistemin her birleşeni bir uygulama olup on iki faktöre uygun olmalıdır.
Aynı kodu paylaşan birden fazla uygulama on iki faktörü ihlal eder. Çözüm paylaşılan kodları kütüphane ile dahil etmek olabilir.
Uygulamanın sadece bir codebase vardır fakat birden fazla dağıtımı olacaktır. Bir dağıtım uygulamanın çalışan bir örneğidir. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır, her biri aynı zamanda dağıtım olarak nitelendirilirler.
Sürümler her bir dağıtımda etkin olabilir fakat kod temeli tüm dağıtımlrda aynıdır. Örneğin geliştiricilerin henüz uygulamaya eklenmemiş commitleri olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod temeli aynıdır.
2) Dependencies(Bağımlılıklar)
Çoğu programlama dili yardım kütüphaneleri dağıtımı için paketleme sistemi sunuyor. Paketleme sistemi sayesinde yüklenen kütüphaneler sistem geneline yüklenir ya da uygulamayı içeren dizinlerdir. Tüm bağımlılılar açıkça bağımlılık bildirimi yoluyla, apacık ve kesin olarak bildirilirler. Ayrıca çevreleyen sistemden itibaren açık bağımlılıkları için uygulama sırasında bir bağımlılık aracı kullanılır. Tam ve açık şartname uygulama ve geliştirmede eşit uygulanır.
Ne olursa olsun araç zinciri, bağımlılık beyanı ve izolasyon her zaman birlikte kullanılmalıdır. Sadece biri on iki faktörü karşılamak için yeterli değildir.
Açık bağımlılık bildiriminin yararlarından biri de yeni geliştiriciler için kurulumu kolaylaştırmasıdır. Yeni geliştiriciler onların geliştirme makineleri üzerinde, uygulama codebase çıktısını kontrol eder, bağımlılık yöneticisi ön koşulları yükler ve sadece çalışma zamanını zorunlu tutar.
3) Config (Yapılandırma)
Bir uygulama yapılandırması çeşitli dağıtımlar arasındaki farklılıkların muhtemel hepsidir. Bunları içerir:
- Kaynak veritabanı, Memcached ve diğer destek hizmetleri kolları
- Dış hizmetlerin(twitter, amazon gibi) kimlik bilgileri
- Dağıtım için dağıtıma göre standart hostname
Uygulamaların bazen koddaki depo yapılandırmaları sabittir. Bu on iki faktöru ihlal eder, bu yapılandırma koddan ayrılmalıdır. Bir turnusol testi için uygulamanın faktor çıktılarının doğru yapılandırılıp yapılandırılmaması, kodun codebasenin herhangi bir zamanda kimlikten ödün vermeden açık kaynak kodlu olup olmadığıdır.
Bu bildirim yapılandırması uygulama içindeki yapılandırmaya dahil edilmez. Yapılandırma dağıtımlar arasında değişmez ve en iyi kod yazılır. Başka bir yaklaşım ise yapılandırma dosyaları kullanılmasıdır örneğin Rails de "config/database.yml" . Bu depo sabitleri kullanarak üzerinde büyük bir değişiklik olduğunda kontrol edilir, ancak yine de zayıflıklar vardır. Yapılandırmayı yönetmek için yapılandırma dosyalarının farklı yerlerde ve farklı biçimlerde olması için bir eğilim vardır. Bundan başka dile veya yapıya özel olma eğilimi vardır.
On iki faktör uygulaması depoları çevre değişkenleri olarak yapılandırılır. Kod değiştirmeden dağıtım arasında geçiş yapmak yapılandırma dosyalarının aksine kolaydır.
Yapılandırma yönetiminin bir diğer yönü gruplandırmadır. Ortamlar olarak gruplandırılır fakat bağımsız olarak her dağıtım için yönetilir. Bu yöntem sorunsuz olarak doğal ömrü boyunca daha fazla dağıtımla genişler.
4) Backing Service(Destek Hizmeti)
Bir destek uygulaması herhangi bir uygulama ağ bölümlerinde, normal işlem üzerinden daha fazla tüketilir. Örneğin, stmp hizmetleri, ön belleğe alma sistemleri, kuyruk sistemleri. Veri tabanı gibi yardım sistemleri bazı sistem yöneticileriyle geleneksel olarak yönetilmeli, uygulama gerçek zamanlı dağıtılmlıdır. Bu yerel yönetim hizmetlerine ek olarak, uygulama aynı zamanda üçüncü şahıslar tarafından sağlanan ve yönetilen servisler olabilir. Örneğin Api, stmp hizmetleri, google maps...
On iki faktör uygulaması için kod yerel ve üçüncü taraf hizmetleri arasında bir ayrım yapmamaktadır. Uygulama da yapılandırma içinde her ikisi de kaynaklara bağlı, url bağlama yolu ya da kimlik saklama ile olmalıdır. On iki faktör uygulamasında bir dağıtım, uygulamanın kodunda herhangi bir değişiklik olmadan üçüncü bir uygulama tarafından yönetilen tek bir yerel MySql veritabanı takası gerektirir. Aynı şekilde bir yerel Stmp sunucusu kod değişikliği olmadan bir üçüncü uygulama Stmp hizmeti ile takas olabilir. Her iki durumda da yapılandırma da sadece kaynak tanıtıcı değiştirilmelidir. Her ayrı destek hizmeti bir kaynaktr. Kaynaklar eklenir ve istediği zaman ayrılabilir.
5) Build,Release,Run(Derle, Sürüm ,Çalıştır)
Bir kod tabanında değişim üç aşamadan oluşur:
- Build aşaması: yapı olarak bilinen bir yürütülebilir paket içini bir kod deposuna dönüştürür.
- Release aşaması: Build aşamasında oluşturulan yapıyı alır ve dağıtmak için mevcut yapılandırma ile birleştirir. Ortaya çıkan yapı yürütme ortamında çalıştırılmak için hazırdır.
- Çalışma aşaması: Uygulama süreçlerini başlatarak yürütme ortamında uygulamayı çalıştırır.
12 faktör uygulaması bu aşamalar arasında katı bir ayrım kullanır. Örneğin zamanında kod değişikliği yapmak mümkün değildir çünkü build aşamasındaki değişiklikleri yaymak için bir yol yoktur. Dağıtım araçları, genellikle sürüm yönetim araçları, bir önceki sürüme almak için olanak sağlar.
Örneğin Capistrano dağıtım aracı sürümleri releases dizini altında tutar, şimdiki sürümü current release dizininde tutar. Geri dönüşü de rollback komutu ile hızlıca sağlar.
Her sürüm her zaman eşsiz bir sürüm id'sine sahip olmalıdır. Herhangi bir değişiklikte yeni bir sürüm oluşturmanız gerekir.
Yeni kod dağıtıldığında her uygulamanın geliştiricileri tarafından build başlatılır. Çalışma zamanlı uygulamalar karşılaştırılmalara göre reboot hizmeti durumunu otomatik yapabilir ya da davetsiz bir süreç, süreç yöneticisi tarafından başlatılabilir. Bu nedenle çalışma aşamasında mümkün olduğunca az hareketli parça tutulmalı, geliştirici elle yapmadığında gece olan kırılmalar uygulama çalışırken önlenir. Dağıtıma sürülen hatalar geliştiriciler için daha önemli olduğundan build aşaması karmaşık olabiliyor.
6) Processes(Süreçler)
Uygulama bir veya daha fazla işlem olarak yürütme ortamında yürütülür. En basit durumda kod bir stand-alone script ile yürütme ortamı bir geliştirici yerel dil çalıştırma ile ve süreç komut satırı ile başlatılabilir.
On iki faktör süreçleri durum bilgisi olmayan, paylaşımdan başka bir şey değildir. Süreklilik gerektiren bir veri bir durum bilgisi olan destek hizmeti, tipik bir veritabanında saklanmalıdır.
Sürecin bellek alanı veya bir dosya sistemi özeti tek aktarımlı önbellek olarak kullanılır. Örneğin büyük bir dosya indirirken üzerinde faaliyet gösteren işlemleri ve veritabanındaki işlemin sonuçlarını saklamak. On iki faktör uygulaması bellek veya disk üzerinden önbelleğe aldıklarını bir iş gelecek veya zaten var olduğunu varsayar. Tek bir süreç çalışırken yeniden başlatma genellikle tüm yereli silecektir.
Varlık paketleyici derlenmiş varlıklar için önbellek olarak dosya sistemi kullanır.
7) Port Binding(Port Bağlamı)
Web uygulamaları bazen bir web sunucusu container'ı içinde yürütülür. Örneğin php uygulamaları apache içinde bir modül olarak çalışabilir veya java uygulamaları Tomcat içinde çalışabilir.
On iki faktör uygulaması tamamen kendi kendine yeter. Bir web uygulaması port bağlayıcısı tarafından servis olarak http ile dışa aktarır ve port üzerinden gelen istekleri dinler.
Bir yerel geliştirme ortamında, geliştiriciler dışa aktarılan servislere erişmek için Url gibi örneğin "http://localhost:5000/" ziyaret ederler. Dağıtımda bir yönlendirme katmanı, port-bound web işlemlerine göre, public-facing ana makineden itibaren yönlendirme isteklerini işler.
Bu tipik uygulama kullanılan bağımlılık bildirimleri tarafından web-server kütüphanelerine eklenir. Bu durum kullanıcı alanında uygulama kodunun içindedir. Yürütme ortamı ile sözleşme istekleri hizmet için bir bağlantı noktasıdır.
Http yalnızca servis değil, port bağlayıcıları tarafından dışa aktarılır. Neredeyse her tür yazılım servisleri için porta göre süreç bağlayıcıları üzerinde çalışır ve gelen istekleri bekler.
Port bağlama yaklaşımının anlamı; tüketen uygulamalar için yapılandırmada cevap olarak işlenen destek uygulamaları ile birlikte, Url sağlayıcıları tarafından bir uygulama, diğer uygulamalar için servis bağlayıcısı olmalıdır.
8) Concurrency(Eş zamanlılık)
Bir bilgisayar programı çalıştırıldığında bir veya bir çok süreç ile temsil edilir. Web uygulamaları süreç yürütme biçimlerinde çeşitlidir. Örneğin Php süreçleri apache için çocuk süreçler çalıştırılır, istek değerleri tarafından gerektiğinde başlatma talep eder. Java süreçleri ters yaklaşım kabul etmektedir. Her iki durumda da çalışan süreçler uygulamalar için geliştiricilere göre minimal görünür.
On iki faktör uygulamasında süreçler birinci sınıf vatandaşlardır. On iki faktör uygulaması süreç servislerini çalıştırmak için unix süreç modellerinden güçlü ipuçları alır. Kullanılan bu model de çalışan süreç tipleri için belirtilen her bir tip tarafından çeşitli iş yükü kullanımına göre diğer uygulamaları planlar. Bu tür bireysel süreçler kendi iç dışlama kullanılarak dışa aktarılmaz, thread üzerinde bulunan çalışma zamanlı VM kullanılır ama bireysel VM çok büyüyebilir, bu nedenle çoklu fiziksel makine üzerindeki bir çok süreci kapsamalıdır. On iki faktör uygulamalarının daha eşzamanlı basit ve güvenirlir bir işlem olduğu anlamına gelir. Bu dizi süreç tipleri için ve her tip süreç numarası için tip formatı olarak biliniyor.
On iki faktör uygulaması süreçleri bekletmez ve PID dosyasına yazmaz. Bunun yerine, çıktı akışlarını yönetmek için işletim sisteminin süreç yöneticisine güvenir, çöken süreçlere cevap verir, kullanıcı üyeliği kabul edilmiş kullanıcı tarafından yeniden başlatılır ve kapatılabilir.
9) Disposability(Kullanıma Hazır Olma Durumu)
Hızlı başlatma ve zarif kapama ile sağlamlık seviyesini en üst düzeye çıkarmak. On iki faktör uygulaması süreçleri kullanıma hazır olmalı, amaç bir anlık bildirimle başlatmak ya da bitirmek. Bu hızlı ölçekleme kod için geliştirimi ve yapılandırma değişikliğini kolaylaştırır ve üretim dağıtımı için sağlamlığı kolaylaştırır. Süreçlerin başlatma süresini en aza indirmek için çaba gerekir. İdeal olarak, süreçlerin bir süre için, sürecin yükselmesine kadar, komut başlatması gerekir ve işlemleri karşılamak için hazırlık zaman almaktadır. Süreci bırakmak, yükseltmek ve yardım sağlamak için kısa başlama süresi atiklik sağlayacak. Çünkü süreç yöneticisi izin verdiğinde yeni fiziksel makineler için süreç hareketi kolaylaşacak. Süreç işlem yöneticisinden SIGNTERM sinyali aldığında duracaktır.
Web süreçlerinde zarif kapatma, port servisleri üzerinde dinleme kesilmesiyle elde edilir, herhangi bir geçerli istek, bitirmek için izin verir ve kapatır.
Çalışan süreç için zarif kapatma, çalışma sırasına göre şimdiki işi dönderme ile elde eder.
Süreçler donanımda bir arıza olması durumunda ani kesilmelere karşı güçlü olmalıdır. Bu SIGTERM ile zarif kapatmada çok daha az sık rastlanan bir durum olmasına rağmen olabilir. Sağlam bir kuyruk olan arka uç kullanılmalıdır. Her iki durumda da, on iki faktör uygulaması beklenmedik işlemleri, zarif olmayan kapanışları planlar. Crash-only tasarım mantıksal sonucuna göre bu kavramı ele alır.
10) Dev/prod parity
Tarihle ilgili ürün ve geliştirme arasında önemli boşluklar oluşmuştur. Bu boşluklar üç alanda gerçekleşir:
- Time gap: Bir geliştiricini üretime geçmek için kod çalışması günler haftalar aylar sürebilir.
- Personel gap: Geliştiriciler kod yazıyor, ops mühendisleri dağıtır.
- Tools gap: Geliştiriciler ürün dağıtımında Apache,MySQL ve linux kullandığında, nginx, SQlite ve OSx gibi bir yığın kullanıyor olabilirler.
On iki faktör uygulaması üretim ile dağıtım arasındaki boşluğu tutarak sürekli dağıtım için tasarlanmıştır. Bu üç boşluğa baktığımız da:
- Time gap küçültmek: Bir geliştirici kod yazdığı zaman saatler hatta dakikalar sonra bile dağıtmak mümkün.
- Personel gap küçültmek: Kod yazan geliştiriciler dağıtımı yakından izlerler.
- Tools gap küçültmek: Üretim ve dağıtım mümkün olduğunca benzer sürdürürler.
Tabloyla özetlemek gerekirse:
Geleneksel uygulama 12 Faktör uygulaması
Dağıtım arasındaki zaman Hafta Saat
Kod yazarları ve kod dağıtıcıları Farklı kisiler Aynı kişiler
Üretim ve geliştirme ortamı Farklı Mümkün olduğunca benzer
Yedekleme hizmeti, veritabanı, kuyruk sistemi ya da önbellek /dev/prod da önemli bir alandır. Bir çok dil yardım hizmetlerine erişimi kolaylaştırmak için kütüphaneler sunar. Bazı geliştiriciler üretimde daha güçlü ve ciddi yardım hizmetlerini kullanmak için yereldeki hafif destek hizmetlerine başvuruyorlar.
12 faktör uygulamaları geliştirme ve dağıtım arasındaki farklı yardım hizmetlerine karşıdır. Destek hizmetleri arasındaki farklılıklar geliştirilirken kod çalıştırma ve test etme bağlantıları kesebilir ya da üretimde fail verebilir. Bu uygulamanın ömrü boyunca düşünüldüğünde maliyeti oldukça artırır.
Hafif yerel destek hizmetleri daha az zorlayıcıdır. Modern yardım hizmetlerinin yüklemesi ve çalıştırması modern paketleme sistemleri sayesinde zor değildir, apt gibi. Bu sistemlerin kurulması ve kullanılmasının maliyeti "dev/prod" bölümü ve sürekli dağıtım yararına oranla düşüktür.
Yeni destek hizmetlerine geçiş yapmak için hala farklı yardım hizmetlerinin uyarlayıcıları kullanılıyor. Fakat tüm dağıtım uygulamalarının kullandıkları tip ve versiyon her bir yardım sistemi için aynı olmalı.
11)Logs (Kayıtlar)
Olay akışlarının işlenmesidir.
Loglar çalışan bir uygulamanın davranışlarında görünürlük sağlar. Sunucu tabanlı ortamlarda genellikle diskteki bir dosyaya yazılır fakat bu sadece bir çıkış yöntemidir. Loglar çalışan süreçlerin ve yardım hizmetlerinin zamanla bağlantılı olay akışlarının toplamıdır. Logların sabit başlangıcı ve sonu yoktur, uygulama çalışırken sürekli akış olur.
12 faktör uygulaması asla çıktı akışını yönelendirme ve depolamayla ilgilenmez. Yazmamalı veya log dosyası yönetmeye kalkışmamalısınız. Bunun yerine, her çalışan süreç olay akışını stduo ile yazıyor. Yerel geliştirme sırasında, uygulama davranışlarını kendi terminalinde gözlemlemek için akışları ön plan da izler. Her işlem akışı ele alınır çevre ortamları tarafından, diğer uygulama akışlarıyla birlikte karşılaştırılır ve arşivlerde görüntülemek üzere nakledilir. Bu hedef arşiv uygulama tarafından görünür veya yapılandırılabilir değildir. Onun yerine uygulama ortamı tarafından tamamen işlenir. Açık kaynak yönlendiricileri bu amaçla kullanılır(Logplex).
Bir uygulama için olay akışı bir dosyaya yönlendirilebilir veya bir terminalde zamanlı kuyruk üzerinden izlenebilmektedir. En önemlisi, akış bir günlük indeksleme ve analiz sistemine gönderilebilir. Bu sistemler uygulamanın zamana bağlı davranışlarını ölçmek için büyük güç ve esneklik sağlar:
- Geçmişte belirli olayları bulmak.
- Eğilimlerin büyük ölçekli grafikleri.(Örneğin dakika başına istekler)
- Kullanıcı tanımına uygun olarak uyarı verir.( Örneğin hata miktarı belli bir eşiği aştığında uyarı gönderir. )
12) Admin Proccess( Yönetici süreci )
Bir defaya mahsus admin yönetici görevlerini çalıştırmak.
Süreç oluşumu uygulamanın düzenli iş yapması için kullanılan süreç dizisidir. Ayrı olarak, geliştiriciler yönetimi ve bakımını bir defaya mahsus yapmak isterler:
- Veritabanı göçleri çalıştırmak
- Çalıştırılan konsol rasgele kodları çalıştırır veya canlı veritabanına karşı uygulamanın modellerini inceler. Çoğu dil bir Repl'i çalışan yorumlayıcı tarafından sağlar , herhangi bir argüman olmadan veya bazı durumlarda ayrı komutlara sahip olarak.
- Uygulamanın depo içine işlenen tek seferlik komut dosyalarını çalıştırır.
Bir kerelik yönetici işlemleri, uygulamanın düzenli uzun soluklu süreçleri olarak özdeş bir ortamda çalıştırılmalıdır. Çalışan bir sürüme karşı herhangi bir işlem, sürüme dayalı olarak yapılandırılmalı ve benzer kod tabanı kullanılmalıdır. Yönetici Kod senkronizasyon sorunlarını önlemek için uygulama kodu ile göndermeniz gerekir.
Aynı bağımlılık izolasyon teknikleri tüm süreç türlerinde kullanılmalıdır. Örneğin eğer ruby web servisleri bundle exec thin start komutunu kullanıyorsa, veritabanı göçü içinde bundle exec rake db:migrate kullanmalıdır.
12 faktör bir Repl kabuk çıktısında kutular için güçlü dil desteği sağlar bir defaya mahsus. Yerel dağıtımlarda, geliştiriciler uygulamanın çıkış dizini içinde doğrudan kabuk komutu ile tek seferlik yönetici işlemleri başlatırlar. Bir ürün dağıtımında geliştiriciler ssh veya diğer uzak komut erişim mekanizmalarını böyle bir işlemi başlatmak için kullanırlar.
