Hangi Sürüm Yönetimi özellikleri Şelale ve Çevik arasındaki farkı açıklamaya yardımcı olur?


12

DevOps'u birisine açıklarken, şöyle bir soru ortaya çıkar:

Agile metodolojisini kullanan Release Management'ın Waterfall'dan farkı nedir?

Peki, bu farklılıkları bu kitleye açıklamak için ne tür kriterler kullanabilirsiniz?

Yanıtlar:


11

IMO DevOps, Agile gibi bir kültürdür (çevik bir metodoloji seçmeden). Bu nedenle DevOps'u "yapmazsınız".

Bir DevOps Kültürünün parçası olarak Sürekli Dağıtım adlı bir yayın yöntemi "yaparsınız". (tam açıklama, CD'ye daha önce bir yayınlama metodolojisi olarak bahsettiğimi sanmıyorum, ama jetlagged durumumda işe yaradığını düşünüyorum)

Bunu satın alırsanız, kitabı aynı başlık olan Jez Humble'dan yazan kişilerden Sürekli Teslimat tanımı .

Sürekli Teslimat, yeni özellikler, yapılandırma değişiklikleri, hata düzeltmeleri ve deneyler dahil olmak üzere her türlü değişikliği üretime veya kullanıcıların eline güvenli ve hızlı bir şekilde sürdürülebilir bir şekilde alma yeteneğidir.

Amacımız, ister büyük ölçekli dağıtılmış bir sistem, ister karmaşık bir üretim ortamı, gömülü bir sistem, ister bir uygulama olsun, isteğe bağlı olarak gerçekleştirilebilecek öngörülebilir, rutin işleri gerçekleştirmektir.

Tüm bunları, günlük olarak değişiklik yapan binlerce geliştiricinin ekipleri karşısında bile kodumuzun her zaman konuşlandırılabilir bir durumda olmasını sağlayarak başarıyoruz. Bu nedenle, geleneksel olarak "dev tamamlandı" yı izleyen entegrasyon, test ve sertleştirme aşamalarını ve kod donmalarını tamamen ortadan kaldırıyoruz.

Böylece, çevik bir metodolojide çalışabilir, işletmeye gösterebileceğiniz bir yazılıma sahip olabilir, uygun otomatik testler yaptığınızdan, değişikliği ve şelaleden daha iyi yapan tüm şeylere iyi tepki verdiğinizden emin olabilirsiniz. Çoğu zaman bu gelmez aslında üretime dağıtmak olabilir demek.

Böyle bir şeyle sonuçlanırsınız: cd olmadan çevik

Böylece, yazılım tamamlandığında (muhtemelen) daha iyi olacaktır, o zaman bir çeşit yinelemeli yaklaşımınız yoksa, ama gerçekten bilmiyorsunuz çünkü gerçek kullanıcılar bunu hiç görmedi.

Gerçekten istediğiniz daha çok şuna benzer:

resim açıklamasını buraya girin

Her yineleme, üretime bir şey dağıtılır. Böylece, yazılım dağıtılır . İndirmeler oluşturmaya karar verirseniz, web sunucusunu açın veya yazılımı yayınlandığı kullanıcıların ellerine alın .

Ne halt!? DevOps'u sordum! Kimse Sürekli Teslimat hakkında soru sormadı !!

Peki DevOps'un bununla ne ilgisi var?

Yazılımınız, ekip DevOps kültüründe çalışmadığı sürece, yazılımınızı istediğiniz zaman dağıtabileceğiniz bir duruma getirmek gerçekten çok zor (imkansızdır). System Admins, DBA, SREs, Security People, Devs, QA, vs.'nin tek bir ekibin parçası olduğu ve aktarımları olan bir kuruluşun sessiz parçası olmadığı bir kültür.

Not :

Bu yanıta gönderilen bir yorumun bir kısmı hakkında, şöyleydi:

"... yazılımınızı istediğiniz zaman dağıtabileceğiniz bir durumda ...": "otomatik pilot" yazılımı (bir düzlemde) hakkında hatırlatıyor ... Bununla ilgili en sevdiğim soru: " Bir güncelleme hayal edin böyle bir yazılıma uygulanır ... Uçakta bunu yapmakla ilgili ne düşünüyorsunuz ... Uçaktayken? ".

Bu soruyu seviyorum (kalın, yukarıdaki alıntıda)! "Gerçekten hazır mı?" Fikri her zaman rant yaptığım bir şey - blog . IMO, CD uygulamak için güvenlik, performans ve diğer "ikincil" testlerden emin olmanız çok önemlidir. Özellikler bittiğinde yapılır, ancak bilgisayar korsanları her zaman oradadır.


İlginç bakış açılarınız / cevaplarınız (ve parlak görüntüler ...) için teşekkür ederiz. Yayın Metodolojisi terimini hiç duymadığımı itiraf etmeliyim , ancak Yayın Yönetimi oldukça aşina olduğum şeydir (2 yıldan fazla bir süredir ...). "... yazılımınız hakkında istediğiniz zaman dağıtabileceğiniz bir durumda ..." ("jetlagged" ile birlikte): "otomatik pilot" yazılımı (bir düzlemde) bununla ilgili soru: " Böyle bir yazılıma bir güncelleme uygulandığını düşünün ... Bu uçuşta ne yapmak istiyorsunuz? Gemideyken? ".
Pierre.Vriens

1
Bu soruyu seviyorum! "Gerçekten hazır mı?" Fikri her zaman rant yaptığım bir şey - blog . IMO, CD uygulamak için güvenlik, performans ve diğer "ikincil" testlerden emin olmanız çok önemlidir. Özellikler bittiğinde yapılır, ancak bilgisayar korsanları her zaman oradadır.
Ken Mugrage

1
Şunu söylüyordum - "Böyle bir yazılıma bir güncelleme uygulandığını hayal edin ... Bu kadar uçuş yapmayı nasıl hissedersiniz ... Gemideyken?"
Ken Mugrage

Ve lütfen düzenle, ben burada bir n00b :)
Ken Mugrage

İlginç yorumunuzu da entegre etmek için lütfen önerilen düzenlememi inceleyin. Eğer beğenmediyseniz, önceki sürüme geri dönün (bağlantı "revizyonlar" içindedir) ve / veya istediğiniz gibi geliştirin / uzatın. Bilin bakalım, "izinler" in bir kısmının "uçuşa geçtiği" gibi görünüyor ... Bu tür önerilen düzenlemeler için hâlâ "onaylara" ihtiyacım var. yazılımı (hava trafik kontrolünden önceden onay almadan bir uçuşun bazı güzergahları için önerilen bir güncelleme değildir). Oeps 2 (düzeltme): ışık hızında onaylandı ...
Pierre.Vriens

2

Başkaları olup olmadığından emin değilim, ancak kullandığım kriterler bunlar:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

Ve farkı gerçekten bir yazılımın kullanıcısı olarak görmek istiyorsanız, o zaman bu sürümlerden birini kullanmak arasında seçim yapabileceğiniz bazı yazılımları (Linux dağıtımı gibi) kullanmayı düşünün:

  • " Rolling" sürümü (==> Çevik).

  • bir " Long Term Support" sürümü (==> Şelale).


1
Linux örneği çok ilham verici olmayabilir :) Şahsen aşağıdakilerden dolayı yuvarlanan sürümlerden hoşlanmıyorum: 1. kalite seviyesi ve 2. oldukça rahatsız edici değişiklikler (benim için kullandığım linux'a değil, işime odaklanmayı tercih ederim iş). Bu yüzden uzun (tahmini) terimleri kullanıyorum (genellikle EOL'lerini geçtikten sonra) ve her 2-3 yılda bir büyük bir güncellemeye odaklanıyorum. Yaşlanma nedeniyle değişime karşı çekişmeyi arttırmadıkça? :)
Dan Cornilescu

@DanCornilescu Bu Linux örneğini kullandım çünkü her iki yöntem için de "a" serbest bırakma mgnt yönünün (yani serbest bırakma sıklığı) aşırı bir örneği olduğunu düşünüyorum. "Kişisel olarak" olsa da, bahsettiğiniz aynı nedenlerden ötürü, yayın bültenlerini beğenmemenize tamamen katılıyorum.
Pierre.Vriens
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.