Bu üç terim arasındaki fark nedir? Üniversitem aşağıdaki tanımları vermektedir:

Sürekli Entegrasyon temel olarak geliştiricinin çalışan kopyalarının günde birkaç kez paylaşılan bir ana hatla senkronize edildiği anlamına gelir.

Sürekli Teslimat , sürekli entegrasyonun mantıksal gelişimi olarak tanımlanır: Bir ürünü her zaman üretime sokabiliriz!

Sürekli Dağıtım , sürekli teslimattan sonraki bir sonraki mantıklı adım olarak tanımlanır: Ürünü, KG'yi geçtiğinde otomatik olarak üretime dağıtın!

Ayrıca bir uyarı sağlarlar: Test sistemine sürekli olarak konuş verebiliyorsanız bazen "Sürekli Dağıtım" terimi de kullanılır.

Bütün bunlar beni şaşırtıyor. Biraz daha ayrıntılı (veya bir örnekle birlikte gelen) herhangi bir açıklama takdir edilmektedir!

Sürekli Entegrasyon

Üniversitenizin tanımını kabul ediyorum. Sürekli Entegrasyon , bir geliştiricinin sık sık aksine, kodu ana hatta sürekli olarak nasıl entegre edebileceğine ilişkin bir stratejidir.

Bunun sürüm kontrol sisteminizde yalnızca bir dallanma stratejisi olduğunu iddia edebilirsiniz.

Bir geliştiriciye atadığınız görevlerin boyutu ile ilgilidir; Bir görevin 4-5 adam-gün süreceği tahmin ediliyorsa, geliştiricinin önümüzdeki 4-5 gün boyunca hiçbir şey teslim etme isteği olmayacaktır, çünkü henüz hiçbir şey yapmamıştır.

Yani boyut önemlidir:

small task = continuous integration
big task   = frequent integration

İdeal görev büyüklüğü bir günlük çalışmadan daha büyük değildir. Bu şekilde bir geliştirici doğal olarak günde en az bir entegrasyona sahip olacaktır.

Sürekli Teslimat

Sürekli Teslimat içinde temel olarak üç okul vardır:

Sürekli Teslimat, Sürekli Entegrasyonun doğal bir uzantısıdır

Bu okul en bakışlar Addison-Wesley "Martin Fowler" imza serisi ve 2007 yayımı çağrıldı beri varsayım yapar "Sürekli Entegrasyon" ve 2011 yılında izledi biri denirdi "Sürekli Teslim" muhtemelen hacmi olan 1 + 2 aynı kavramsal fikrin sürekli bir şeyle ilgisi vardır .

Sürekli Teslimat, Çevik Yazılım Geliştirme ile ilgilidir

Bu okul, Sürekli Teslimat'ın sadece kavramsal bir fikir ya da niyet mektubu olarak değil, gerçek hayatta gerçek hayatta da çevik hareketin prensiplerini destekleyebileceği fikrinden yola çıkmaktadır .

"Sürekli teslimat" teriminin ilk defa kullanıldığı Agile Manifestosunda ilk prensipte dengeleme :

En yüksek önceliğimiz, değerli yazılımların erken ve sürekli teslimi ile müşteriyi memnun etmektir.

Bu okul, "Sürekli Teslimat" ın "tamamlanmış tanımınız" için otomatik bir doğrulama uygulamak için gereken her şeyi kapsayan bir paradigma olduğunu iddia ediyor .

Bu okul, "Sürekli Teslim" ve vızıltı kelimesinin ya da mega devri "DevOps" un, sadece bir teknik değil, bu yeni paradigmayı veya yaklaşımı benimsemeye çalıştıkları için aynı madalyonun çevirme tarafları olduğunu kabul eder.

Sürekli Dağıtım, Sürekli Dağıtım ile eşanlamlıdır

Üçüncü okul, Sürekli Dağıtım ve Sürekli Teslimat'ın aynı anlama gelmek için birbirinin yerine kullanılabileceğini savunuyor .

Geliştiricilerin elinde bir şey hazır olduğunda, hemen son kullanıcılara teslim edilir, bu da çoğu durumda üretim ortamına dağıtılması gerektiği anlamına gelir. Dolayısıyla "Dağıtma" ve "Teslim etme" aynı anlama gelir.

Hangi okula katılacak

Üniversiteniz ilk okula açıkça katıldı ve aynı yayın serisinin 1 + 2 cildine atıfta bulunduğumuzu iddia ediyor. Benim düşüncem, bunun Sürekli Teslimat teriminin kötüye kullanılmasıdır.

Ben şahsen Sürekli Teslimat'ın çevik hareketin ifade ettiği fikir ve kavramlar için gerçek yaşam desteği uygulamakla ilgili olduğunu savunuyorum . Bu yüzden, terimin "DevOps" gibi bir paradigmayı kucakladığını söyleyen okula katıldım.

Kullanan okul teslimatı için eşanlamlı olarak dağıtmak çoğunlukla vadeli daha yaygın kullanımından yutturmaca biraz almaya çalışırken, dağıtım konsolları oluşturmak aracı satıcıları tarafından savunulmaktadır Sürekli Teslimat .

Sürekli Dağıtım

Sürekli Dağıtım'a odaklanma, çoğunlukla son kullanıcının yazılım güncellemelerine erişiminin bu bilgiler için bazı merkezi kaynakların güncellenmesine bağlı olduğu ve bu merkezi kaynağın her zaman kolay olmadığı, çünkü monolitik olduğu veya (çok) yüksek tutarlılığa sahip olduğu alanlarla ilgilidir. doğaya göre (web, SOA, Veritabanları vb.).

Merkezi bilgi kaynağı olmayan (aygıtlar, tüketici ürünleri, istemci kurulumları vb.) Veya merkezi bilgi kaynağının güncellenmesinin kolay olduğu (uygulama depoları artefakt yönetim sistemleri, Açık Kaynak depoları vb.) Yazılım üreten birçok alan için ), Sürekli Dağıtım terimi hakkında neredeyse hiç bir aldatmaca yoktur. Sadece konuşlandırıyorlar; büyük bir şey değil - özel bir odaklanma gerektiren bir acı değil.

Sürekli Dağıtım'ın herkes için genel olarak ilginç bir şey olmaması, aynı zamanda "teslimat" ve "konuşlandırmanın" eşanlamlı olduğunu iddia eden okulun her şeyi yanlış yaptığını iddia ediyor. Çünkü Sürekli Teslimat, cihazlarda gömülü yazılım yapıyor veya bir çerçeve için Açık Kaynak eklentilerini yayınlamış olsanız bile, herkes için gerçekten iyi bir anlam ifade eder.

Üniversitenizin Sürekli Dağıtım'ın Sürekli Teslimatın doğal bir sonraki adımı olduğunu tanımlaması, KG tarafından gönderilen her teslimatın derhal son kullanıcılara sunulması gerektiğini varsayar ve kabilemin "Sürekli" terimini tanımlamak için kullandığı tanıma daha yakın Release ", bu da herkes için genel olarak anlamlı olmayan başka bir kavram.

Bir yayın çok stratejik veya politik bir şey olabilir ve herkesin bunu her zaman yapmak isteyeceğini varsaymak için hiçbir neden yoktur (çevrimiçi bir kitapçı bir akış hizmeti türü şirket olmadıkça). Bununla birlikte, her şeyi körü körüne serbest bırakmayan şirketlerin yine de dağıtımın efendisi olmak istedikleri birçok nedeni olabilir, bu yüzden Sürekli Dağıtım da yaparlar . Değil üretime ancak salım salım-adaylarına karşı üretim benzeri ortamlarda.

Yine üniversitenin yanlış anladığına inanıyorum. "Sürekli Sürüm" için "Sürekli Dağıtım" ı yanlış yapıyorlar.

Sürekli dağıtım, bir geliştirme sürecinin sonucunu, fonksiyonel testin tam ölçekte gerçekleştirilebileceği üretime benzer bir ortama sürekli olarak taşıyabilmenin disiplinidir.

Sürekli Teslimat Hikayesi

Resimde her şey canlanıyor:

Sürekli Entegrasyon süreci, durum geçiş şemasındaki ilk iki eylemdir. hangi - başarılı olursa - tamamının tanımını uygulayan Sürekli Teslim boru hattını başlatır . Dağıtım, bu boru hattında sürekli olarak yapılması gereken birçok eylemden sadece biridir. İdeal olarak, işlem geliştiricinin VCS'ye taahhüt ettiği noktadan boru hattının geçerli bir serbest bırakma adayımız olduğunu doğruladığı noktaya kadar otomatiktir.

Ne soru ne de cevaplar bu konudaki basit düşünme şeklime uymuyor. Ben bir danışmanım ve bu tanımları bir dizi Dev ekibi ve DevOps kişisiyle senkronize ettik, ancak bunun sektörle genel olarak nasıl eşleştiğini merak ediyorum:

Temelde sürekli teslimat gibi çevik sürekli uygulama düşünüyorum:

Sürekli değil (her şey manuel)% 0 ---->% 100 Sürekli Değer Teslimi (her şey otomatik)

Sürekli dağıtım yolunda atılacak adımlar:

Sıfır. Devs check-in kodu geldiğinde hiçbir şey otomatik değildir ... Check-in öncesinde herhangi bir test gerçekleştirmiş, derlenmiş veya çalıştırılmışsa şanslısınız.

1. Sürekli Yapı: Her check-in sırasında otomatik inşa, ilk adımdır, ancak yeni kodun işlevsel entegrasyonunu kanıtlamak için hiçbir şey yapmaz.

2. Sürekli Entegrasyon (CI): yeni kodun mevcut kodla entegrasyonunu, tercihen entegrasyon testlerini (uçtan uca) kanıtlamak için en az birim testlerin otomatik olarak oluşturulması ve yürütülmesi.

3. Sürekli Dağıtım (CD): kod CI'yi en azından bir test ortamına geçtiğinde, tercihen kalite CI yoluyla veya manuel testten sonra daha düşük bir ortam PASSED olarak işaretlendiğinde daha yüksek ortamlara geçtiğinde otomatik dağıtım. IE, test bazı durumlarda manuel olabilir, ancak bir sonraki ortama yükseltmek otomatiktir.

4. Sürekli Teslimat: otomatik yayın ve sistemin üretime geçmesi. Bu CD üretime ek olarak A / B testi için kurulum, yeni özelliklerin kullanıcılarına bildirim, yeni sürüm desteğini bildirme ve notları değiştirme gibi diğer yapılandırma değişiklikleri.

EDIT: Agile Manifesto'nun ilk prensibinde ( http://agilemanifesto.org/principles.html ) atıfta bulunulan "sürekli teslimat" kavramı ile Sürekli Teslimat pratiği arasında bir fark olduğunu belirtmek isterim , sorunun bağlamında atıfta bulunulduğu anlaşılmaktadır. Sürekli teslimat ilkesi, Yalın düşüncede ( http://www.miconleansixsigma.com/8-wastes.html ) açıklandığı gibi Envanter atıklarını azaltmaya çalışmaktır . Çevik ekipler tarafından Sürekli Teslimat (CD) uygulaması, Agile Manifesto'nun 2001 yılında yazılmasından bu yana uzun yıllar ortaya çıkmıştır. Bu çevik uygulama, farklı şeyler olmasına ve görünüşte kolayca karışmasına rağmen, doğrudan ilkeye hitap etmektedir.

Amazon tanımının anlaşılması kolay ve basit olduğunu düşünüyorum .

" Sürekli dağıtım , yayınlama sürecinin otomatikleştirildiği bir yazılım geliştirme metodolojisidir. Her yazılım değişikliği otomatik olarak oluşturulur, test edilir ve üretime dağıtılır. Üretime son itmeden önce, bir kişi, otomatik test veya iş kuralı, Her başarılı yazılım değişikliği derhal sürekli teslimatla üretime sunulabilse de, tüm değişikliklerin hemen yayınlanması gerekmez.

Sürekli entegrasyon , bir ekibin üyelerinin bir sürüm kontrol sistemi kullandıkları ve çalışmalarını bir ana dal gibi aynı yere sık sık entegre ettikleri bir yazılım geliştirme uygulamasıdır. Her değişiklik, mümkün olan en kısa sürede tüm entegrasyon hatalarını tespit etmek için testler ve diğer doğrulamalarla oluşturulur ve doğrulanır. Sürekli entegrasyon, tüm yazılım yayınlama sürecini üretime kadar otomatik hale getiren sürekli teslimatla karşılaştırıldığında otomatik olarak kod oluşturmaya ve test etmeye odaklanır . "

Lütfen http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html adresini ziyaret edin

Atlassian, Sürekli entegrasyon ile sürekli dağıtım ve sürekli dağıtım hakkında iyi bir açıklama yaptı .

Kısaca:

Sürekli Entegrasyon - şubeye her yeni giriş yapıldığında uygulamayı oluşturmak ve test etmek için bir otomasyondur.

Sürekli Dağıtım - Sürekli Entegrasyon + Uygulamayı "bir butona tıklayarak" üretime dağıtın (Müşterilere bırakma genellikle talep edilir).

Sürekli Dağıtım - Sürekli Teslimattır, ancak insan müdahalesi olmadan (Müşterilere sürüm devam etmektedir).

Sürekli Entegrasyon temel olarak geliştiricinin çalışan kopyalarının günde birkaç kez paylaşılan bir ana hatla senkronize edildiği anlamına gelir.

Veya günde birkaç kereden fazla. Temelde verilen herhangi bir ayrık görev kadar sık. Örneğin, tek bir iş uygulaması üzerinde çalışan bir geliştiriciler ekibini düşünün. Birçok ortamda aşağıdakiler olabilir:

• Bir veya iki geliştirici, "henüz hazır değil" için birkaç gün boyunca yerel değişiklikleri koruyor.
• Bir ya da iki geliştirici, kaynak denetiminde "diğer insanların değişimlerinden rahatsız olmadan özelliklerinde" çalışabilmeleri için dallar oluşturur.

Bunlar sorunlara yol açabilir. Kötü kod / görev organizasyonu dallanmaya yol açar, dallanma birleşmeye, birleştirmeye ... acı çekmeye yol açar. Bir uygulama olarak sürekli entegrasyon, herkesi aynı paylaşılan kaynaktan çalışmaya teşvik ederek bunu ele alır. Bireysel iş kalemleri kısa sürede (en fazla saat) tamamlanacak kadar ayrık olmalıdır.

Temel olarak genel fikir, küçük bir değişikliğin az miktarda çalışmaya entegre edilmesidir. Büyük bir değişikliği entegre etmek orantısız olarak büyük miktarda çalışmadır. Sabit küçük adımlarla yapılırsa entegrasyon çalışmalarının toplamı daha küçüktür. Bu, geliştiricilerin geliştirme süreci yükü yerine iş tarafından görülebilir özellikler üzerinde daha fazla zaman harcamasına olanak tanır.

Sürekli Teslimat, sürekli entegrasyonun mantıksal gelişimi olarak tanımlanır: Bir ürünü her zaman üretime sokabiliriz!

Bu, aynı ayrık, iyi tanımlanmış iş kalemleri fikrini takip eder. Tam, test edilmiş, bilinen çalışma özellikleri ile yalnızca küçük artışlarla ayarlanan tek bir ana kod tabanı varsa, kod tabanı her zaman kararlıdır. Otomatik test, bir düğmeye basarak bu dengeyi kanıtlayabilmek için çok önemlidir.

Yapılması gereken daha az stabilizasyon çalışması (yine, geliştirme süreci yüküdür ve ortadan kaldırılmalıdır), bu kod tabanı herhangi bir ortama daha sık itilebilir. Birçok şirkette dağıtım oldukça yorucu bir süreç olabilir. Bir hafta süren güvertede bile operasyon. Bu pahalıdır ve hiçbir iş değeri üretmez. İyi iş öğesi tanımları, etkili otomatik testler ve sürekli entegrasyon kullanarak bir ekip, kod tabanının herhangi bir ortama dağıtımını otomatikleştirecek bir konumda olabilir.

Sürekli Dağıtım, sürekli teslimattan sonraki bir sonraki mantıksal adım olarak tanımlanır: Ürünü, KG'yi geçtiğinde otomatik olarak üretime dağıtın!

Bunun bir iş ortamında nadiren görüldüğünü göreceksiniz ve karşılaşıldığında oldukça büyük bir keyif. Kod tabanı otomatik olarak test edilebilir ve herhangi bir ortama otomatik olarak dağıtılabilirse, üretim diğer ortamlar gibi bir ortamdır. Eğer ekip bu noktaya geldiyse, o zaman üretim güncellemelerini her zaman devreye sokarak işletmeye önemli bir değer katar.

Hata düzeltmeleri müşterilere daha hızlı gönderilir, yeni özellikler pazara daha hızlı ulaşır, yeni fikirler, önceliklerin yeniden yönlendirilmesini sağlamak için pazara karşı daha küçük artışlarla test edilir.

Örneğin, bir şirketin yazılım tabanlı ürün veya hizmetlerinde yeni bir özellik için büyük bir fikri olduğunu varsayalım. Biraz araştırma yaptılar, pazarı biliyorlar ve bu fikrin yeni ve güçlü bir gelir çizgisi ile sonuçlanacağına inanıyorlar. Şimdi bu özelliği sunmak için iki seçeneği göz önünde bulundurun:

1. Her şeyi tek seferlik bir dalda geliştirerek aylar geçirin. Haftaları ana kod tabanına entegre ederek geçirin. Günleri test ederek geçirin. Dağıtmak için bir gün geçirin. Ve ancak o zaman üretim sistemindeki gerçek geliri izlemeye başlayın.
2. Özelliğin küçük parçalarını birer birer uygulayın. Her hafta yeni bir parça çıkar. Her hafta gerçek gelir hakkında daha fazla veri alın.

İlk senaryoda, özellik istenen pazar etkisine sahip değilse, müşterilerin gerçekten istemediği bir şey için çok para harcanır. İkinci senaryoda, müşterilerin istemediği gerçeği çok, çok daha erken belirlenir ve işin geri kalanının önceliği kaldırılır.

Nihayetinde bu "sürekli şeyler" tamamen geliştirme süreci yükünü kaldırmakla ilgilidir. Bir şirketin gelir hattı belirli bir hizmet teklifi ise, ideal olarak tüm maliyetleri bu teklife dahil edilmelidir. Geliştirme süreci yükü (kod birleştirme, birleştirme işleminden sonra aynı özellikleri yeniden test etme, manuel dağıtım görevleri vb.) Aslında hizmetin değerine katkıda bulunmaz, bu nedenle bu kavramlar bu maliyetleri işlemden çıkarmaya çalışır.

Bir grafik birçok kelimenin yerini alabilir:

Zevk almak! :-)

# Doğru resmi güncelledim ...

Sürekli Entegrasyon, Sürekli dağıtım ve sürekli dağıtım arasındaki fark

Sanırım fazla analiz ediyoruz ve belki de "sürekli" sözcük grubunu biraz karmaşık hale getiriyoruz. Bu bağlamda sürekli otomasyon demektir. "Sürekli" ye bağlı diğer kelimeler için İngilizce'yi çeviri rehberiniz olarak kullanın ve lütfen işleri karmaşıklaştırmaya çalışmayın! "Sürekli derleme" uygulamasında, uygulamamızı otomatik olarak belirli bir platform / kapsayıcı / çalışma zamanı / vb. İçin yürütülebilir bir şeye dönüştürüyoruz (yaz / derle / link / etc). "Sürekli entegrasyon", yeni işlevlerinizin başka bir varlıkla etkileşimde bulunurken amaçlandığı şekilde test ve performans gösterdiği anlamına gelir. Açıkçası, entegrasyon gerçekleşmeden önce, derleme gerçekleşmelidir ve entegrasyonu doğrulamak için kapsamlı testler de kullanılacaktır. Yani, "sürekli entegrasyon" kişi, mevcut bir işlevsellik grubuna, mevcut işlevselliği olumsuz yönde etkilemeyecek, aksine onunla güzel bir şekilde bütünleşen, bütüne algılanan bir değer katacak şekilde otomasyon kullanır. Entegrasyon, sadece İngilizce tanımıyla, şeylerin ahenkli bir şekilde jive olduğunu ima ediyor, bu yüzden kod konuşmamda derlemeler, bağlantılar, testler ve bütün içinde mükemmel bir şekilde çalışıyor. Son üründe başarısız olsaydı entegre bir şey demezdin, değil mi ?! Bağlamımızda "Sürekli dağıtım", "sürekli dağıtım" ile eşanlamlıdır, çünkü günün sonunda müşterilerimize işlevsellik sağladık. Ancak, bunu aşırı analiz ederek, konuşlandırmanın bir dağıtım alt kümesi olduğunu iddia edebilirim çünkü bir şeyi dağıtmak, teslim ettiğimiz anlamına gelmez. Kodu konuşlandırdık, çünkü Paydaşlarımızla etkin bir şekilde iletişim kurarak, iş perspektifinden teslim edemedik! Birlikleri konuşlandırdık ama vaat edilen su ve yiyecekleri yakındaki şehre teslim etmedik. "Sürekli geçiş" terimini ekleseydim, kendi değeri olurdu? Sonuçta, kodun ortamlar boyunca hareketini tanımlamak daha uygundur, çünkü kalıcı olarak yalnızca bir konum anlamına gelebilecek konuşlandırma veya dağıtımdan daha çok "çağrışımdan" çağrışımına sahiptir! Sağduyu uygulamazsak, elde ettiğimiz şey budur. kendi değeri var mı? Sonuçta, kodun ortamlar boyunca hareketini tanımlamak daha uygundur, çünkü kalıcı olarak yalnızca bir konum anlamına gelebilecek konuşlandırma veya dağıtımdan daha çok "çağrışımdan" çağrışımına sahiptir! Sağduyu uygulamazsak, elde ettiğimiz şey budur. kendi değeri var mı? Sonuçta, kodun ortamlar boyunca hareketini tanımlamak daha uygundur, çünkü kalıcı olarak yalnızca bir konum anlamına gelebilecek konuşlandırma veya dağıtımdan daha çok "çağrışımdan" çağrışımına sahiptir! Sağduyu uygulamazsak, elde ettiğimiz şey budur.

Sonuç olarak, bu tarif etmek basit şeyler (bunu yapmak biraz daha ... karmaşık!), Sadece sağduyu, İngilizce dili kullanın ve iyi olacaksınız.

Sürekli Entegrasyon: Kodun sorunları yakalamak için mümkün olduğunca sık test edilmesi için geliştirme çalışmasını ana dalla sürekli birleştirme uygulaması.

Sürekli Teslimat: Kod gönderilmeye hazır olduğunda kodun bir ortama sürekli olarak gönderilmesi. Bu evreleme veya üretim olabilir. Fikir, ürünün inceleme ve inceleme için KG veya müşteri olabilecek bir kullanıcı tabanına teslim edilmesidir.

Sürekli Entegrasyon aşamasındaki birim testi, tüm hataları ve iş mantığını, özellikle de kalite kontrolüne ihtiyacımız olan tasarım konularını veya test için hazırlama ortamını yakalayamaz.

Sürekli Dağıtım: Kod hazır olur olmaz konuşlandırılır veya yayınlanır. Sürekli Dağıtım, Sürekli Entegrasyon ve Sürekli Teslimat gerektirir, aksi takdirde sürümde kod kalitesi garanti edilmez.

Sürekli Dağıtım ~~ Sürekli Entegrasyon + Sürekli Teslimat

Sürekli Entegrasyon

• Otomatik (check-in inşası + birim testi)

Sürekli Teslimat

• Sürekli Entegrasyon
• Otomatik (ortamı test etmek için dağıtım + yük testi + entegrasyon testi)
• Manuel (üretime dağıtım)

Sürekli Dağıtım

• Sürekli Teslimat ancak otomatik (üretime dağıtım)

CI / CD bir yolculuktur. Bir hedef değil.

Bu aşamalar birer öneridir. Aşamaları iş ihtiyaçlarınıza göre uyarlayabilirsiniz. Bazı aşamalar çoklu test, güvenlik ve performans türleri için tekrarlanabilir. Projenizin karmaşıklığına ve ekiplerinizin yapısına bağlı olarak, bazı aşamalar farklı seviyelerde birkaç kez tekrarlanabilir. Örneğin, bir takımın son ürünü bir sonraki takımın projesine bağımlı olabilir. Bu, ilk ekibin son ürününün daha sonra bir sonraki ekibin projesinde bir eser olarak sahnelendiği anlamına gelir.

Dipnot:

AWS'de Sürekli Entegrasyon ve Sürekli Teslimat Uygulaması

Kaynak: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

Sürekli Entegrasyon Nedir? Sürekli Entegrasyon, otomatik derleme ve otomatikleştirilmiş testin bir süreci veya geliştirme uygulamasıdır, yani bir geliştiricinin, her bir tümleştirmenin otomatik derleme ve testle doğrulandığı, kodunu birden çok kez paylaşılan bir depoya koyması gerekir.

Derleme başarısız olursa / başarılı olursa geliştiriciye bildirilir ve ardından ilgili işlemleri yapabilir.

Sürekli Teslim Nedir Sürekli Teslim, kodumuzu tüm testi geçen ve kodu üretime zorlamak için gereken tüm yapılandırmaya sahip olan ancak henüz konuşlandırılmayan herhangi bir noktada konuşlandırılabilir tutmamızdır.

Sürekli Dağıtım Nedir CI yardımıyla uygulamamız için bir yapı oluşturduk ve üretime geçmeye hazırız. Bu adımda derlememiz hazırdır ve CD ile uygulamamızı doğrudan KG ortamına dağıtabiliriz ve her şey yolunda giderse aynı derlemeyi üretime dağıtabiliriz.

Temel olarak, Sürekli dağıtım, sürekli dağıtımdan bir adım daha uzaktır. Bu uygulama ile üretim hattınızın tüm aşamalarından geçen her değişiklik müşterilerinize bırakılmaktadır.

Sürekli Dağıtım, Yapılandırma Yönetimi ve Kapsayıcılığın bir birleşimidir.

Konfigürasyon Yönetimi: CM, uygulama gereksinimlerine uygun sunucu konfigürasyonunu korumakla ilgilidir.

Kapsayıcılık : Kapsayıcılık, çevre genelinde tutarlılığı sağlayacak bir dizi ücrettir.

Görüntü kaynağı: https://www.atlassian.com/

DevOps 3C'lerin bir kombinasyonudur - sürekli , iletişim , işbirliği ve bu da çeşitli endüstrilerde öncelikli odaklanmaya yol açar.

IoT bağlantılı cihazlar dünyasında, ürün sahibi, web, mobil ve QA gibi çoklu scrum özellikleri, bir ürünü son müşteriye ulaştırmak için scrum döngüsünün bir scrum döngüsünde çevik bir şekilde çalışır.

Sürekli entegrasyon: Birden fazla uç noktasında aynı anda çalışan çoklu scrum özelliği

Sürekli teslimat: Entegrasyon ve dağıtım ile, aynı anda ele alınacak birden fazla müşteriye ürün teslimatı.

Sürekli dağıtım: birden çok müşteriye birden çok platformda dağıtılan birden çok ürün.

DevOps'un IoT bağlantılı dünyayı nasıl etkinleştirdiğini öğrenmek için bunu izleyin: https://youtu.be/nAfZt2t4HqA

Sürekli Teslimat ve DevOps kursunda Alex Cowan ile öğrendiklerimden , CI ve CD, bir Gözlemden Serbest Bırakılan Bir Ürüne kadar geçen sürede oluşan bir ürün hattının bir parçasıdır.

Gözlemlerden Tasarımlara kadar amaç yüksek kalitede test edilebilir fikirler elde etmektir. Sürecin bu kısmı Sürekli Tasarım olarak kabul edilir .

Bundan sonra ne olacak, Koddan itibaren gittiğimizde , amacı fikirleri çok hızlı bir şekilde yürütmek ve müşteriye çok hızlı bir şekilde sunmak olan Sürekli Teslimat yeteneği olarak kabul edilir (Jez Humble'ın Sürekli Teslimat: Build, Test ile Güvenilir Yazılım Sürümleri, ve daha fazla ayrıntı için Dağıtım Otomasyonu ). Aşağıdaki ardışık düzende, Sürekli Tümleştirme (CI) ve Sürekli Dağıtım (CD) adımlarının hangi bölümlerden oluştuğu açıklanmaktadır.

Mattias Petter Johansson'ın açıkladığı gibi Sürekli Entegrasyon ,

bir yazılım ekibinin günde birden fazla birleştirme yapma alışkanlığı olduğu ve bu birleştirmeleri sorun olup olmadığını kontrol etmek için otomatik bir doğrulama sistemine sahip olduğu zamandır.

(daha pratik bir genel bakış için CircleCI - CircleCI kullanmaya başlama - Sürekli Entegrasyon P2 ve Çekme İsteğinde CircleCI'yi Çalıştırma ) için aşağıdaki iki videoyu izleyebilirsiniz ).

Yeni Kod'dan piyasaya sürülen bir Ürüne giden CI / CD boru hattını aşağıdaki gibi belirtebilirsiniz.

İlk üç adım Testler ile ilgilidir ve test edilenin sınırını genişletir.

Sürekli Dağıtım ise, Dağıtımı otomatik olarak yönetmektir. Böylece, otomatik test aşamasını geçen herhangi bir kod taahhüdü otomatik olarak üretime bırakılır.

Not : Boru hatlarınızın nasıl olması gerektiği bu değildir, ancak referans olarak hizmet edebilirler.

kısa tutalım:

CI: Bir ekibin üyelerinin çalışmalarını en az günlük olarak entegre ettiği bir yazılım geliştirme uygulaması. Her entegrasyon, hatayı olabildiğince çabuk tespit etmek için otomatik derleme (testler dahil) tarafından doğrulanır. CD: CD Yazılımları istediğiniz zaman üretime alınabilecek şekilde geliştirdiğiniz CI üzerine kurulur.