DevOps ve Yazılım Yapılandırma Yönetimi arasındaki fark

Geliştirme İşlemleri ile Yazılım Yapılandırma Yönetimi arasındaki fark nedir?

Benim için hem DevOps hem de Yazılım Yapılandırma Yönetimi'ne odaklandığı sürece aynı görünüyor:

1. Kurulması geliştirme altyapısını - versiyon sorumlu olmak kontrolü, yapı yönetimi, dağıtım yönetimi, bağımlılıkları yönetimi, sürekli entegrasyon ve teslimat vb
2. Geliştirici ortamını organize etmek için en iyi uygulamaları kullanmak .
3. Geliştirme süreçlerinin Kalite Güvencesi - geliştirme etkinliği metriklerini toplamak, geliştirme sürecinin darboğazlarını ortadan kaldırmak için çalışmak (birim testleri yapmak, birim testleri kapsamını değerlendirmek, denetimleri yürütmek, vb.)
4. Altyapı yönetimi - hedef platformlar ve özellikleri.
5. Sürüm yönetimi - sürümün müşteriye / müşteriye zamanında teslim edildiğinden emin olmak.

Belki bir şey eksik? Bu bağlantı , 'Yazılım Yapılandırma Yönetimi' teriminin kullanımının geçerli olduğunu gösterir. Ancak yine de, listelenen faaliyetleri tanımlamak için hangi kelime kombinasyonunu kullanmayı tercih edersiniz: Geliştirme İşlemleri veya Yazılım Yapılandırma Yönetimi ?

Terimler çok benzer kavramları ve sorumlulukları tanımlar ve genel olarak eşanlamlıdır. "DevOps" terimi Devopsdays Ghent 2009 konferansı ve müteakip Devopsdays etkinlikleri tarafından popüler olan nispeten yeni bir terimdir . En iyi bu diyagramda açıklanmıştır :

Diğer yandan, Yazılım Yapılandırma Yönetimi mesleğin içinde çok daha köklü bir terimdir ve yazılıma özgü olmayan Yapılandırma Yönetimi teriminden türemiştir . Yazılım Yapılandırma Yönetimi'ne genellikle yazılım mühendisliği bağlamında atıfta bulunulur, Roger Pressman tarafından "Yazılım Mühendisliği: Bir Uygulayıcının Yaklaşımı" nda basit bir tanım verilir :

değişmesi muhtemel iş ürünlerini belirleyerek, aralarında ilişki kurarak, bu iş ürünlerinin farklı sürümlerini yönetmeye yönelik mekanizmaları tanımlayarak, yapılan değişiklikleri kontrol ederek ve yapılan değişiklikleri denetleyerek ve raporlayarak değişimi kontrol etmek için tasarlanmış bir dizi faaliyettir.

Başvurduğunuz tüm terimler belirsiz olsa da, DevOps, bir yazılım geliştiricisinin bakış açısından görüldüğünde, özellikle sıkı bir şekilde bağlı ekiplere öncelik vererek, Yapılandırma Yönetimi veya Yazılım Yapılandırma Yönetimi ile aynı ilkeleri tanımlamanın daha az resmi bir yolu gibi görünmektedir :

DevOps, geleneksel olarak geliştirme faaliyeti olarak bilinen ve geleneksel olarak faaliyet faaliyeti olarak kabul edilen şey arasında bir kopukluk olduğunun farkındalığına verilen yanıttır. Bu kopukluk genellikle çatışma ve verimsizlik olarak kendini gösterir.

Aynı makalede, SCM ile benzerlikler not edilmiştir:

Karışıklık Duvarına eklemek, geliştirme ve operasyon araçlarında çok yaygın uyumsuzluktur. Geliştiricilerin günlük olarak talep ettiği ve kullandığı popüler araçlara göz atın. Ardından, sistem yöneticilerinin günlük olarak talep ettiği ve kullandığı popüler araçlara göz atın. Hata izleyicileri ve belki de SCM gibi birkaç önemli istisna dışında, birbirlerinin araçlarını veya aralarındaki önemli entegrasyonu kullanmaya çok fazla ilgi duyacağınızdan şüpheleniyoruz. Araç türlerinde bazı çakışmalar olsa bile, uygulamalar her grupta farklı olacaktır.

Terimlerin kullanımına gelince, karşılaştırmanız gerçekten mantıklı değil:

1. SCM, CM'nin bir alt kümesidir, rekabetçi bir terim değildir,
2. DevOps oldukça yeni bir terimdir, belirlenmiş terimlerle karşılaştırmanın anlamı yoktur,
3. DevOps, Geliştirici İşlemlerinden (açıkçası) kaynaklanır, ancak nadiren bu şekilde genişletilir.

Şahsen uzun yıllar bir Sr. Yazılım Yapılandırma Yöneticisi olarak (10+) çeşitli gerçek yaşam durumlarında uyuşmayan terimleri duyuyorum. Pozisyonların göreceli doğası nedeniyle teknik olmayan personel için nadir değildir. Her ikisinin de benzer, ancak benim görüşüme göre açıkça bölünebilen belirli rolleri, ihtiyaçları ve gereksinimleri var.

Bu rollerin bölünmesini tanımlamanın en iyi yolunun etkileşime göreliliğine odaklanmak olduğuna inanıyorum. Bunun anlamı, Yazılım Yapılandırma Yönetimi, kaynak kodun entegrasyonu, dağıtımı, yayınlanması ve yönetimi ile birlikte dahili sistemlere ve ortamlara odaklanır. Geliştirici İşlemleri (DevOps) olarak, dış kaynaklı uygulama mimarisinin operasyonel yönüne daha fazla odaklanırken, kodun kullanım amacına ve çevresine uygulanmasına ilişkin net bir anlayış korunur. Bir makinenin performansı bozulma belirtileri gösteriyorsa, birden fazla uygulama arasındaki iletişim arızalı, işletmeler arası (BtB) iletişim ve / veya bir üretim ortamına ilişkin mimari sınırlamalar varsa, teşhisleri için Geliştirici İşlemlerine bakarsınız ve çözüm.

Tipik olarak, tecrübelerime göre, Yazılım Yapılandırma Yöneticisi bunları da yapabilir, ancak bu, ortam yapılandırmalarını ve yazılım revizyonlarını izleme, yönetme ve dağıtma konusundaki temel odaklarından uzaklaşır. Görevlerin ayrılmasını sağlayan yazılım, hata ve hata izleme, proje izleme ve yazılım geliştirme yaşam döngüsü ve solucanın yönetilmesi. Bu görevler Geliştirici İşlemlerinin ana odağı değildir ve bu nedenle daha az zorunludur, ancak yine de yapılabilir.

Her birinin karışıklığının birçok örneğini gördüm ve her birinde sınırlı bir geçiş var. Bununla birlikte, bağımsız pozisyonların her birinin birincil odaklarına ilişkin sorumlulukları arasındaki farkları düşünmek en önemlisidir. Öncelikle, ortamların yapılandırmasını ve ürünün piyasaya sürülmesini yönetmek için dahili olarak kullanılan sistem ve donanımlarla uğraşırken, bir Yazılım Yapılandırma Yöneticisi ararsınız. Öte yandan, müşterileriniz tarafından kullanılan sistemlerin sistem performansı, izlenmesi, araştırılması ve teşhisi ile ilgilenirken, Geliştirici İşlemlerine veya DevOps'a bakmalısınız.

Şimdi, bu bir rant, ne de kesin bir cevap değil, her bir pozisyonun farklılıklarının kişisel bir tanımlamasıdır. Bu konuda iyi olup olmadığımı veya bu cevaba göre işler daha net hale getirilip getirilmediğini bilmek istiyorum.

DevOps için sağlam bir tanım bulmakta zorlanıyorsunuz. Yapılacak bir işten daha çok bir fikir. Ve herkesin tam olarak ne anlama geldiğini kabul etmesi çok yeni bir fikir. Yine de, benim almam.

DevOps gerçekten yapılandırma yönetimi için yeni bir terim, ancak rolün tek kişilik bir rol olmadığını, geliştirme ekibi ile operasyon ekibi arasında bir işbirliği olduğunu göstermek için seçildi.

Tarihsel olarak, konfigürasyon yönetimi sadece geliştirme ekibi tarafından yapılacak ve daha sonra hepsini derin bir kuşku ile görecek operasyonlara dağıtılacaktı. Bu dürüst olmak gerekirse yeterince adil. Bundan sorumlular. Yanlış gittiğinde sabah saat 4'te ilk arananlar bunlar. Gerçekten onların gelişimine bazı katılımları olmalı.

Bu sorunun basit açıklamasıdır: DevOps, Geliştirme (geliştirme ortamında program kodlarının geliştirilmesi) ve Operasyonlar (üretim ortamının maksimum çalışma süresini sağlama) arasındaki koordinasyonu veya ilişkiyi tanımlamak için kullanılan bir terimdir.

Yazılım Yapılandırma Yönetimi bu koordinasyonu sağlamanın bir yoludur. SCM, geliştirmeden üretime geçiş sürecinin otomasyonunu yönetmek için araçlar ve teknikler içeriyordu (operasyonlar)

Özetlemek gerekirse, SCM Dev ve Ops'u birbirine bağlar.

DEVOP'ların operasyonel yürütme sonunda dağıtım otomasyon komut dosyalarında, çevre yapılarında, bu tür şeylerde olduğunu görüyorum. Öte yandan SCM, ürünlerin bütünlüğü ve ürünlerdeki değişikliklerin etkili yönetimi ve izlenebilirliği ile ilgilidir. ALM'yi her zaman SCM'nin bir parçası olarak gördüm - sonuçta, değişiklik için sürücüler hakkında hiçbir fikriniz yoksa veya bunları kimin yaptığını varsa, bir üründe değişiklikleri nasıl yönetebilirsiniz? Dağıtım çerçeveleri her iki tarafa da düşebilir - ve hangi taraf, çalıştığınız kuruluşun düzenleyici ihtiyaçlarına bağlı olacaktır - sonuçta - bir geliştiricinin hızlı bir saldırı yapabilmesini ister misiniz, bu da diyaliz makinenizin sadece% 99,99'unun düzgün çalıştığı anlamına gelir veya geliştiricilerinizin sabit kodlu IP adresleri olduğu için web sitesi kodunuzu hacklemenize izin vermek için bu duruma mı ihtiyacınız var?