İlk önce küçük bir teori. Ne oldu ?
Basit bir ifadeyle bu belge, SaaS uygulamalarının geliştirilmesini basitleştirmek, geliştiricileri ve DevOps mühendislerini modern uygulamaların geliştirilmesinde en sık karşılaşılan sorunlar ve uygulamalar hakkında bilgilendirerek yardımcı olmak için tasarlanmıştır.
Belge Heroku platformunun geliştiricileri tarafından oluşturuldu.
Twelve-Factor Uygulaması, herhangi bir programlama dilinde yazılmış ve herhangi bir destek hizmeti kombinasyonunu (veritabanları, mesaj kuyrukları, önbellekler vb.) kullanan uygulamalara uygulanabilir.
Kısaca bu metodolojinin dayandığı faktörler hakkında:
- Kod tabanı – Sürüm kontrolünde izlenen bir kod tabanı – birden fazla dağıtım
- Bağımlılıklar – Bağımlılıkları açıkça beyan edin ve izole edin
- Yapılandırma – Yapılandırmayı çalışma zamanında kaydedin
- Destek Hizmetleri – Destek hizmetlerini eklenti kaynakları olarak düşünün
- Oluşturun, yayınlayın, çalıştırın – Montaj ve uygulama aşamalarını kesin olarak ayırın
- süreçler – Uygulamayı bir veya daha fazla durum bilgisi olmayan süreç olarak çalıştırın
- Liman bağlantısı – Bağlantı noktası bağlama yoluyla hizmetleri dışa aktarma
- paralellik – Süreçleri kullanarak uygulamanızı ölçeklendirin
- Tek kullanımlık – Hızlı başlatma ve temiz kapatma ile güvenilirliği en üst düzeye çıkarın
- Uygulama geliştirme/işletim eşitliği – Geliştirme, hazırlama ve üretim ortamlarınızı mümkün olduğunca benzer tutun
- Kerestecilik – Günlüğü bir olay akışı olarak görüntüleyin
- Yönetim görevleri – Geçici süreçleri kullanarak yönetim/yönetim görevlerini gerçekleştirin
Aşağıdaki kaynaklardan 12 faktör hakkında daha fazla bilgi alabilirsiniz:
- - okunmalı
- — resmi çeviri
- - 12 faktöre iyileştirme amacıyla yeni bir bakış.
Mavi-Yeşil dağıtımı nedir?
Mavi-Yeşil dağıtım, bir uygulamayı üretim son müşterinin kendi tarafında herhangi bir değişiklik görmemesini sağlayacak şekilde. Başka bir deyişle, bir uygulamayı sıfır değerle dağıtmak Kesinti.
Klasik BG Dağıtım şeması aşağıdaki resimde gösterilene benzer.
- Başlangıçta kesinlikle aynı koda, uygulamaya, projeye sahip 2 fiziksel sunucu vardır ve bir yönlendirici (dengeleyici) vardır.
- Yönlendirici başlangıçta tüm istekleri sunuculardan birine yönlendirir (yeşil).
- Tekrar yayınlamanız gerektiğinde, projenin tamamı başka bir sunucuda güncellenir (mavi), şu anda herhangi bir isteği işlememektedir.
- Kod açıldıktan sonra mavi Sunucu tamamen güncellendiğinde, yönlendiriciye geçiş yapması için bir komut verilir. yeşil üzerinde mavi sunucu.
- Artık tüm istemciler çalıştırılan kodun sonucunu görüyor mavi sunucu.
- Belli bir süre için, yeşil sunucu, başarısız dağıtım durumunda yedek kopya görevi görür mavi sunucu ve arıza veya hata durumunda, yönlendirici kullanıcı akışını tekrar sunucuya geçirir. yeşil Sunucu eski kararlı sürüme sahip olup, yeni kod revizyon ve test için gönderilir.
- Ve işlem sonunda aynı şekilde güncellenir. yeşil sunucu. Ve bunu güncelledikten sonra yönlendirici istek akışını tekrar şuna çevirir: yeşil sunucu.
Her şey çok iyi görünüyor ve ilk bakışta herhangi bir sorun olmamalı.
Ancak modern dünyada yaşadığımız için klasik şemada belirtildiği gibi fiziksel anahtarlama seçeneği bize uymuyor. Şimdilik bilgileri kaydedin, daha sonra döneceğiz.
Kötü ve iyi tavsiye
Feragatname: Aşağıdaki örnekler benim kullandığım yardımcı programları/metodolojileri göstermektedir; benzer işlevlere sahip tüm alternatifleri kesinlikle kullanabilirsiniz.
Örneklerin çoğu şu ya da bu şekilde web geliştirmeyle (bu bir sürpriz), PHP ve Docker ile kesişecek.
Aşağıdaki paragraflar, belirli örnekler kullanarak faktörlerin kullanımına ilişkin basit ve pratik bir açıklama sunmaktadır; bu konu hakkında daha fazla teori edinmek istiyorsanız, yukarıdaki orijinal kaynağa giden bağlantıları izleyin.
1. Kod Tabanı
Dosyaları sunuculara teker teker yüklemek için FTP ve FileZilla kullanın; kodu üretim sunucusu dışında herhangi bir yerde saklamayın.
Projenin her zaman tek bir kod tabanı olmalı, yani tüm kodlar tek bir kaynaktan gelmelidir. Git depo. Sunucular (üretim, aşamalandırma, test1, test2...) ortak bir havuzun dallarından gelen kodları kullanır. Bu şekilde kod tutarlılığına ulaşıyoruz.
2. Bağımlılıklar
Klasörlerdeki tüm kütüphaneleri doğrudan projenin kök dizinine indirin. Yeni kodu, kitaplığın geçerli sürümünün bulunduğu klasöre aktararak güncellemeler yapın. Gerekli tüm yardımcı programları doğrudan 20 hizmetin daha çalıştığı ana sunucuya yükleyin.
Bir projede her zaman açıkça anlaşılabilen bir bağımlılık listesi bulunmalıdır (bağımlılık derken çevreyi de kastediyorum). Tüm bağımlılıklar açıkça tanımlanmalı ve izole edilmelidir.
Örnek olarak ele alalım Oluşturmak и liman işçisi.
Oluşturmak — PHP'de kitaplıklar yüklemenizi sağlayan bir paket yöneticisi. Composer, sürümleri kesin veya gevşek bir şekilde belirtmenize ve bunları açıkça tanımlamanıza olanak tanır. Sunucuda 20 farklı proje olabilir ve her birinin birbirinden bağımsız kişisel paket ve kütüphane listesi olacaktır.
liman işçisi — uygulamanın çalışacağı ortamı tanımlamanıza ve izole etmenize olanak tanıyan bir yardımcı program. Buna göre tıpkı bestecide olduğu gibi ama daha detaylı olarak uygulamanın neyle çalıştığını belirleyebiliriz. Belirli bir PHP sürümü seçin, ekstra bir şey eklemeden yalnızca projenin çalışması için gerekli paketleri yükleyin. Ve en önemlisi, ana makinenin ve diğer projelerin paketlerine ve ortamına müdahale etmeden. Yani, Docker aracılığıyla çalışan sunucudaki tüm projeler kesinlikle herhangi bir paket setini ve tamamen farklı bir ortamı kullanabilir.
3. Yapılandırma
Yapılandırmaları doğrudan kodda sabitler olarak saklayın. Test sunucusu için ayrı sabitler, üretim için ayrı sabitler. Uygulamanın ortama bağlı çalışmasını if else yapılarını kullanarak doğrudan projenin iş mantığına bağlayın.
konfigürasyonları - proje dağıtımlarının farklı olmasının tek yolu budur. İdeal olarak, konfigürasyonlar ortam değişkenleri (env vars) aracılığıyla aktarılmalıdır.
Yani, birkaç yapılandırma dosyası .config.prod .config.local depolasanız ve dağıtım sırasında bunları .config (uygulamanın verileri okuduğu ana yapılandırma) olarak yeniden adlandırsanız bile - bu doğru bir yaklaşım olmayacaktır çünkü bu durumda konfigürasyonlardan gelen bilgiler tüm uygulama geliştiricilerin kullanımına açık olacak ve üretim sunucusundaki veriler tehlikeye atılmış olacaktır. Tüm konfigürasyonların doğrudan dağıtım sisteminde (CI/CD) saklanması ve dağıtım sırasında belirli bir ortam için gerekli olan farklı değerlere sahip farklı ortamlar için oluşturulması gerekir.
4. Üçüncü Taraf Hizmetleri
Ortama sıkı sıkıya bağlı olun, belirli ortamlarda aynı hizmetler için farklı bağlantılar kullanın.
Aslında bu nokta, konfigürasyonlarla ilgili noktayla güçlü bir şekilde örtüşmektedir, çünkü bu nokta olmadan normal konfigürasyon verileri yapılamaz ve genel olarak konfigürasyon yeteneği sıfıra düşer.
Kuyruk sunucuları, veritabanları, önbellekleme hizmetleri gibi harici hizmetlere yapılan tüm bağlantılar hem yerel ortam hem de üçüncü taraf/üretim ortamı için aynı olmalıdır. Başka bir deyişle, herhangi bir zamanda bağlantı dizesini değiştirerek, uygulama kodunu değiştirmeden 1 numaralı baz istasyonuna yapılan çağrıları 2 numaralı baz ile değiştirebilirim. Veya ileriye baktığımızda, örneğin hizmeti ölçeklendirirken, ek bir önbellek sunucusu için bağlantıyı herhangi bir özel şekilde belirtmeniz gerekmeyecektir.
5. Oluşturun, yayınlayın, yürütün
Kodun yalnızca son sürümünü sunucuda bulundurun ve sürümü geri alma şansınız yok. Disk alanını doldurmanıza gerek yok. Kodu üretime hatayla çıkarabileceğini düşünen herkes kötü programcıdır!
Dağıtımın tüm aşamaları birbirinden ayrılmalıdır.
Geri dönme şansın var. Uygulamanın eski kopyalarını (halihazırda toplanmış ve savaşa hazır) hızlı erişime kaydedilmiş olarak yayınlayın, böylece hata durumunda eski sürümü geri yükleyebilirsiniz. Yani şartlı olarak bir klasör var bültenleri ve klasör akımve klasörü başarılı bir şekilde konuşlandırıp birleştirdikten sonra akım içinde yer alan yeni sürüme sembolik bir bağlantıyla bağlı bültenleri sürüm numarasının geleneksel adıyla.
Burası yalnızca kodlar arasında geçiş yapmanıza değil, aynı zamanda her şeyi geri alma yeteneğiyle tüm kaynaklar ve hatta ortamlar arasında geçiş yapmanıza olanak tanıyan Mavi-Yeşil dağıtımını hatırladığımız yerdir.
6. Süreçler
Uygulama durumu verilerini doğrudan uygulamanın kendisinde saklayın. Uygulamanın RAM'indeki oturumları kullanın. Üçüncü taraf hizmetler arasında mümkün olduğunca fazla paylaşım kullanın. Uygulamanın yalnızca bir işleme sahip olabileceği ve ölçeklendirmeye izin vermediği gerçeğine güvenin.
Oturumlarla ilgili olarak, verileri yalnızca üçüncü taraf hizmetler (memcached, redis) tarafından kontrol edilen bir önbellekte saklayın; böylece çalışan 20 uygulama işleminiz olsa bile, önbelleğe erişen bunlardan herhangi biri istemciyle çalışmaya devam edebilecektir. kullanıcının başka bir işlemde uygulamayla çalıştığı durumun aynısı. Bu yaklaşımla, üçüncü taraf hizmetlerin kaç kopyasını kullanırsanız kullanın, her şeyin normal şekilde ve verilere erişimde sorun olmadan çalışacağı ortaya çıkıyor.
7. Bağlantı noktası bağlama
Üçüncü taraf hizmetlerle nasıl çalışılacağını yalnızca web sunucusu bilmelidir. Veya daha da iyisi, üçüncü taraf hizmetleri doğrudan web sunucusunun içine yükleyin. Örneğin Apache'de bir PHP modülü olarak.
Tüm hizmetleriniz, bazı adres ve bağlantı noktalarına (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) erişim yoluyla birbirine erişilebilir olmalıdır, yani nginx'ten hem php-fpm'ye hem de postgres ve php-fpm'den postgres ve nginx'e ve aslında her hizmetten başka bir hizmete erişebiliyorum. Bu şekilde, bir hizmetin uygulanabilirliği başka bir hizmetin uygulanabilirliğine bağlı değildir.
8. Paralellik
Tek bir süreçle çalışın, aksi takdirde birden fazla süreç birbiriyle anlaşamayacaktır!
Ölçeklendirme için yer bırakın. Docker sürüsü bunun için mükemmeldir.
Docker Swarm, hem farklı makineler hem de aynı makinedeki bir grup konteyner arasında konteyner kümeleri oluşturmaya ve yönetmeye yönelik bir araçtır.
Swarm'ı kullanarak, her bir işleme ne kadar kaynak ayıracağımı ve aynı hizmetin kaç sürecini başlatacağımı belirleyebilirim ve belirli bir bağlantı noktasında veri alan dahili dengeleyici, bunu otomatik olarak süreçlere proxy olarak yönlendirir. Böylece sunucudaki yükün arttığını görerek daha fazla işlem ekleyebiliyorum, böylece belirli işlemlerin yükünü azaltabiliyorum.
9. Tek kullanımlıklık
Süreçler ve verilerle çalışmak için kuyrukları kullanmayın. Bir işlemin öldürülmesi uygulamanın tamamını etkilemelidir. Bir hizmet aksarsa her şey bozulur.
Her işlem ve hizmet herhangi bir zamanda kapatılabilir ve bu durum diğer hizmetleri etkilememelidir (tabii ki bu, hizmetin başka bir hizmet için kullanılamayacağı anlamına gelmez, ancak bundan sonra başka bir hizmetin kapatılmayacağı anlamına gelir). Tüm süreçlerin zarif bir şekilde sonlandırılması gerekir, böylece sonlandırıldığında hiçbir veri zarar görmez ve sistem bir sonraki açışınızda doğru şekilde çalışır. Yani, acil sonlandırma durumunda bile verilerin zarar görmemesi gerekir (işlem mekanizması burada uygundur, veritabanındaki sorgular yalnızca gruplar halinde çalışır ve gruptan en az bir sorgu başarısız olursa veya bir sorgu ile yürütülürse) hatası varsa, o zaman gruptan gelen başka hiçbir sorgu aslında başarısız olmaz).
10. Uygulama geliştirme/işletme eşitliği
Uygulamanın prodüksiyonu, sahnelenmesi ve yerel versiyonu farklı olmalıdır. Üretimde Yii Lite çerçevesini ve yerel olarak da Yii'yi kullanıyoruz, böylece üretimde daha hızlı çalışır!
Gerçekte, tüm dağıtımlar ve kodla yapılan çalışmalar neredeyse aynı ortamda olmalıdır (fiziksel donanımdan bahsetmiyoruz). Ayrıca, gerekirse herhangi bir geliştirme çalışanı kodu üretime dağıtabilmelidir ve yalnızca özel güç sayesinde uygulamayı üretime kaldırabilen özel eğitimli devops departmanı değil.
Docker da bu konuda bize yardımcı oluyor. Önceki tüm noktalara dikkat edilirse, docker'ın kullanılması, ortamın hem üretimde hem de yerel makinede dağıtılması sürecini bir veya iki komutun girilmesiyle getirecektir.
11. Günlükler
Günlükleri dosyalara ve veritabanlarına yazıyoruz! Günlüklerden dosya ve veritabanlarını temizlemiyoruz. 9000 Peta baytlık bir sabit disk satın alalım ve bunda sorun yok.
Tüm günlükler bir olay akışı olarak değerlendirilmelidir. Uygulamanın kendisi günlüklerin işlenmesinde yer almamalıdır. Logların ya stdout'a çıktısı alınması ya da udp gibi bir protokol üzerinden gönderilmesi gerekmektedir, böylece loglarla çalışmak uygulama açısından herhangi bir sorun yaratmaz. Graylog bunun için iyidir. Tüm logları udp üzerinden alan Graylog (bu protokol, paketin başarılı bir şekilde alındığına dair yanıt beklenmesini gerektirmez), uygulamaya hiçbir şekilde müdahale etmez ve sadece logların yapılandırılması ve işlenmesiyle ilgilenir. Uygulama mantığı bu tür yaklaşımlarla çalışacak şekilde değişmez.
12. Yönetim görevleri
Verileri, veritabanlarını vb. güncellemek için API'de ayrı olarak oluşturulmuş bir uç nokta kullanın; bunun arka arkaya 2 kez yürütülmesi her şeyin kopyalanmasına neden olacaktır. Ama aptal değilsin, iki kez tıklamayacaksın ve geçişe ihtiyacımız yok.
Tüm yönetim görevleri, tüm kodlarla aynı ortamda, sürüm düzeyinde gerçekleştirilmelidir. Yani veritabanının yapısını değiştirmemiz gerekiyorsa bunu bazı görsel veritabanı yönetim araçlarıyla sütunların adlarını değiştirip yenilerini ekleyerek manuel olarak yapmayacağız. Bu tür şeyler için, her yerde ve her ortamda aynı şekilde yürütülen, ortak ve anlaşılır bir sonuçla yürütülen ayrı komut dosyaları - geçişler oluştururuz. Projeyi verilerle doldurmak gibi diğer tüm görevler için benzer metodolojiler kullanılmalıdır.
PHP, Laravel, Laradock, Docker-Compose'ta örnek uygulama
PS Tüm örnekler MacOS'ta yapılmıştır. Çoğu Linux için de uygundur. Windows kullanıcıları kusura bakmayın ama uzun süredir Windows ile çalışmıyorum.
Bilgisayarımızda herhangi bir PHP sürümünün yüklü olmadığı ve hiçbir şeyin yüklü olmadığı bir durumu hayal edelim.
Docker ve docker-compose'un en son sürümlerini yükleyin. (bu internette bulunabilir)
docker -v &&
docker-compose -v
1. Koy
git clone https://github.com/Laradock/laradock.git &&
ls
Laradock'a gelince, içinde çok sayıda konteyner ve yardımcı şey barındıran çok güzel bir şey olduğunu söyleyeceğim. Ancak yedekliliği nedeniyle Laradock'u üretimde değişiklik yapmadan bu şekilde kullanmanızı tavsiye etmem. Laradock'taki örneklere dayanarak kendi kaplarınızı oluşturmak daha iyidir, bu çok daha optimize olacaktır çünkü kimsenin aynı anda orada olan her şeye ihtiyacı yoktur.
2. Uygulamamızı çalıştırmak için Laradock'u yapılandırın.
cd laradock &&
cp env-example .env
2.1. Habr dizinini (laradock'un klonlandığı ana klasör) bir düzenleyicide açın. (Benim PHPStorm durumumda)
Bu aşamada projeye sadece isim veriyoruz.
2.2. Çalışma alanı görüntüsünü başlatın. (Sizin durumunuzda görüntülerin oluşturulması biraz zaman alacaktır)
Workspace, geliştirici adına framework ile çalışmak için özel olarak hazırlanmış bir imajdır.
Kullanarak kabın içine giriyoruz
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel'in Kurulumu
composer create-project --prefer-dist laravel/laravel application
2.4. Kurulumdan sonra projeyi içeren dizinin oluşturulup oluşturulmadığını kontrol ediyoruz ve compose'u sonlandırıyoruz.
ls
exit
docker-compose down
2.5. PHPStorm'a geri dönelim ve .env dosyasındaki laravel uygulamamızın doğru yolunu ayarlayalım.
3. Kodun tamamını Git'e ekleyin.
Bunu yapmak için Github'da (veya başka bir yerde) bir depo oluşturacağız. Terminaldeki habr dizinine gidip aşağıdaki kodu çalıştıralım.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Her şeyin yolunda olup olmadığını kontrol edelim.
Kolaylık sağlamak için Git için bazı görsel arayüzler kullanmanızı öneririm, benim durumumda . (burada bir yönlendirme linki var)
4. Haydi başlayalım!
Başlamadan önce 80 ve 443 numaralı bağlantı noktalarında hiçbir şeyin asılı olmadığından emin olun.
docker-compose up -d nginx php-fpm
Yani projemiz 3 ayrı hizmetten oluşuyor:
- nginx-web sunucusu
- php-fpm - bir web sunucusundan istekleri almak için php
- çalışma alanı - geliştiriciler için php
Şu anda 4 üzerinden 12 puanı karşılayan bir uygulama oluşturmayı başardık:
1. Kod tabanı — tüm kod tek bir depodadır (küçük not: laravel projesinin içine docker eklemek doğru olabilir, ancak bu önemli değildir).
2. Bağımlılıklar - Tüm bağımlılıklarımız application/composer.json dosyasında ve her konteynerin her Docker dosyasında açıkça yazılmıştır.
3. Destek Hizmetleri — Hizmetlerin her biri (php-fom, nignx, çalışma alanı) kendi hayatını yaşar ve dışarıdan bağlanır ve bir hizmetle çalışırken diğeri etkilenmez.
4. süreçler — her hizmet bir süreçtir. Hizmetlerin her biri dahili durumu korumaz.
5. Liman bağlantısı
docker ps
Görüldüğü gibi her servis kendi portunda çalışmaktadır ve diğer tüm servisler tarafından erişilebilir durumdadır.
6. paralellik
Docker, aralarında otomatik yük dengeleme ile aynı hizmetlerin birden fazla sürecini oluşturmamıza olanak tanır.
Konteynerleri durduralım ve bayrağın üzerinden geçirelim --ölçek
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Gördüğümüz gibi php-fpm konteynerinin kopyaları oluşturuldu. Bu konteynerle çalışırken hiçbir şeyi değiştirmemize gerek yok. Ayrıca 9000 numaralı bağlantı noktasından da erişmeye devam ediyoruz ve Docker, konteynerler arasındaki yükü bizim için düzenliyor.
7. Tek kullanımlık - her konteyner diğerine zarar vermeden öldürülebilir. Container'ın durdurulması veya yeniden başlatılması, uygulamanın sonraki başlatmalarda çalışmasını etkilemeyecektir. Her konteyner herhangi bir zamanda kaldırılabilir.
8. Uygulama geliştirme/işletim eşitliği -tüm ortamlarımız aynı. Sistemi üretimdeki bir sunucuda çalıştırdığınızda komutlarınızda herhangi bir değişiklik yapmanıza gerek kalmayacaktır. Her şey aynı şekilde Docker'ı temel alacak.
9. Kerestecilik — bu kapsayıcılardaki tüm günlükler akışa gider ve Docker konsolunda görünür. (bu durumda aslında diğer ev yapımı kaplarda, eğer bakımını yapmazsanız durum böyle olmayabilir)
docker-compose logs -f
Ancak PHP ve Nginx'teki Varsayılan değerlerin de günlükleri bir dosyaya yazması gibi bir sorun var. 12 faktörün karşılanması için gerekli kapatmak günlüklerin her konteynerin konfigürasyonlarındaki bir dosyaya ayrı ayrı yazılması.
Docker ayrıca sadece stdout'a değil, yukarıda bahsettiğim Graylog gibi şeylere de log gönderme olanağı sağlıyor. Graylog içerisinde ise logları istediğimiz gibi çalıştırabiliriz ve uygulamamız bunu hiçbir şekilde fark etmeyecektir.
10 Yönetim görevleri — tüm yönetim görevleri, artisan aracı sayesinde laravel tarafından tam olarak 12 faktörlü uygulamanın yaratıcılarının istediği gibi çözülür.
Örnek olarak bazı komutların nasıl yürütüldüğünü göstereceğim.
Konteynere giriyoruz.
docker-compose exec workspace bash
php artisan list
Artık herhangi bir komutu kullanabiliriz. (lütfen veritabanını ve önbelleği yapılandırmadığımızı unutmayın; bu nedenle komutların yarısı, önbellek ve veritabanıyla çalışacak şekilde tasarlandıkları için doğru şekilde yürütülmeyecektir).
11 konfigürasyonları ve 12. Oluşturun, yayınlayın, çalıştırın
Bu bölümü Mavi-Yeşil Dağıtım'a ayırmak istedim ancak bu makale için çok kapsamlı olduğu ortaya çıktı. Bu konuyla ilgili ayrı bir makale yazacağım.
Özetle, konsept aşağıdaki gibi CI/CD sistemlerine dayanmaktadır: Jenkins и Gitlab CI. Her ikisinde de belirli bir ortamla ilişkili ortam değişkenlerini ayarlayabilirsiniz. Buna göre bu durumda c maddesi sağlanacaktır. Yapılandırmalar.
Ve bununla ilgili nokta Oluşturun, yayınlayın, çalıştırın adındaki yerleşik işlevlerle çözülür Boru Hattı.
Boru Hattı montaj, sürüm ve yürütme aşamalarını vurgulayarak dağıtım sürecini birçok aşamaya ayırmanıza olanak tanır. Ayrıca Pipeline'da yedeklemeler ve aslında her şeyi oluşturabilirsiniz. Bu sınırsız potansiyele sahip bir araçtır.
Uygulama kodu şurada .
Bu depoyu klonlarken alt modülü başlatmayı unutmayın.
Not: Tüm bu yaklaşımlar diğer yardımcı programlarla ve programlama dilleriyle birlikte kullanılabilir. Önemli olan, özün farklı olmamasıdır.
Kaynak: habr.com