Kılavuz: Küçük Ekipler İçin Yazılım Sürüm Yönetimi

Yayın Yönetim Sürecinin Resmileştirilmesi (Varsa)

Bazı ekip yapılandırmalarında, özellikle başlangıçlarda bulunan yapılandırmalarda, ürünün yeni bir sürümünü yayınlarken destek sağlayacak DevOps veya altyapı mühendisleri yoktur.

Ayrıca, tanımlanmış resmi süreçlere sahip büyük bürokratik şirketlerin aksine, bir startup'taki CTO veya Yazılım Geliştirme Başkanı ekibi genellikle yazılım sürüm yönetimi sürecinin karmaşıklığının farkında değildir; şirketteki birkaç geliştirici, sürecin karmaşık ayrıntılarının farkında olabilir, ancak herkes değil. Bu bilgi tam olarak belgelenmezse , kafa karışıklığına neden olabileceğine inanıyorum.

Bu yazıda, özellikle geliştiricinin bakış açısından, sürüm sürecinin nasıl resmileştirileceğine dair bazı ipuçları vermeye çalışacağım.

Yazılım Sürümü Kontrol Listesini Girin

Atul Gawande'nin bir kitabı olan Kontrol Listesi Manifestosu'na göre bazı işlemler için bir kontrol listesi fikrine aşina olabilirsiniz. Resmi bir yayın sürecinin (yazılım geliştirme dünyasındaki diğer birçok görev gibi) geliştiricilere bu protokolü uygulama fırsatı sunduğuna inanıyorum. Bir yayın süreci kontrol listesi, tercihen ortak bir wiki veya Google Drive'da bir elektronik tablo biçiminde, paylaşılan bir belgede tutulmalıdır.

Bu hayati belgeyi ekiple paylaşarak ve düzenleme izinleri vererek, her üye resmi olarak tanımlanmış yayın sürecine erişebilir. Bu, sürecin nasıl çalıştığını anlamalarını sağlar. Ayrıca, diğer ekip üyeleriyle yapılan tartışmaların ardından, ekibin arada sırada bunu geliştirmesini sağlar. Bu şeffaflık getirmeli ve tüm ekibin sürüm sırasında neler olup bittiğine, hangi adımların tamamlandığına ve kimler tarafından gerçek zamanlı erişime sahip olmasına izin vermelidir.

Paydaşlar, bu elektronik tabloya bakarak, adımların sonucuna göre bir 'DEVAM' veya 'HAYIR DEVAM' kararı verebilirler. Örneğin, bir test ortamında bir stres testi yanlış giderse, olaya bağlı olarak proje yöneticisi üretim sürümünü iptal etmeye karar verebilir.

Fondöten Olarak Kullanmak İçin Önerilen Adımlar

Bu bölümde, yayın süreciniz için kendi kontrol listenizi oluşturmak için kullanabileceğiniz bazı adımlar önereceğim. Bu adımlardan bazıları hiçbir şekilde zorunlu değildir . Her uygulama farklıdır ve her kuruluş farklı bir şekilde çalışır, bu nedenle iş akışınıza daha iyi uyacak şekilde uyarlamaktan ve değişiklikler yapmaktan çekinmeyin.

1. Bir Yayın Dalı Oluşturun

Git İş Akışı kavramına veya önceki bir blog gönderisinde açıklanan bir konu olan sürüm dalları fikrine aşina olmanız muhtemeldir.

İdeal olarak, en az üç şubeniz olmalıdır:

• master : bu, üretim ortamındaki mevcut durumu yansıtmalıdır. Master'daki her yeni taahhüt, yalnızca yeni bir sürüm içermelidir.
• geliştir : bu dal, tamamlanmış (ve test edilmiş) yaklaşan özellikleri içermelidir. Her özellik için ayrı bir dal oluşturmak ve ardından özellik hazır olduğunda geliştirmek için birleştirmek yaygındır.
• yayın : yayın dalları, üretime gönderilmeye hazır olan bir taahhütler koleksiyonunun yanı sıra sürümle ilgili bazı ek küçük hata düzeltmeleridir.

Yayın tamamlandıktan sonra yayın dallarının kaldırılması gerektiğine dikkat edin, bu nedenle bu dallar her zaman aynı olan master veya geliştirmenin aksine her zaman oluşturulur ve yok edilir.

Git terminalinizdeki geliştirme dalından yeni bir sürüm dalı oluşturmak için şunu yazın:

$ git checkout -b release/xyz

İhtiyaçlarınıza göre xyz yerine major.minor.patch sürüm numarasıyla değiştirilerek yukarıda tanımlanan gibi bir adlandırma kuralı kullanmak uygundur (bu, ekibiniz içinde tanımlamanız ve ona bağlı kalmanız gereken bir ilkedir).

Şunu da söylemek önemlidir ki, sürüm dalına bazı hata düzeltmeleri kodlarsanız, bunları geliştirmek için yeniden birleştirmeyi unutmamalısınız. Sürüm dalının temel amacı, uygulamanın üretime girdikten sonra nasıl davranması gerektiğine dair bir önizleme anlık görüntüsüne sahip olmaktır.

2. Çarpma Sürümü

Bir sonraki adım, sürüm dalındaki sürüm numarasını çarpmak (değiştirmek veya artırmak) olacaktır.

AndroidManifest.xml / package.json / pom.xml / dosyasını veya uygulama sürümünün projenizde (YMMV) depolandığı her yerde açmalı, sürüm numarasını güncellemeli ve ardından değişiklikleri geçerli yayın dalına uygulamalısınız.

Sürüm numarasını güncellemek iki nedenden dolayı önemlidir.

İlk olarak, her sürümde sunulan özellikleri izleyebilir ve eşleyebilirsiniz ve ikincisi, bazı sorun giderme işlemleri yapmaları veya destek için sizinle iletişime geçmeleri gerektiğinde kullandıkları sürümün farkında olacaksınız. Bir mobil uygulama oluşturuyorsanız, bu adımda güncellemekte olduğunuz sürüm numarası genellikle kullanıcı tarafında, Hakkında bölümünde veya Google Play veya Apple App Store'da görüntülenir. Bu adım, ortama bağlı güncelleme yapmak için de iyi bir fırsattır. - yapılandırma dosyaları (bunları ayrı bir depoda tutmayı önersem de), şubeyi üretim veritabanına yönlendirmek veya oluşturma sürecinde gereken diğer ince ayarlar gibi.

Son olarak, yayın dalını Origin'e göndermeniz önerilir, böylece diğer geliştiricileriniz için kullanılabilir:

$ git push -u origin release/xyz

3 A. Master ve etiketlemek için yayın dalını birleştirin

Üretim için yalnızca ana dal dağıtılmalıdır, bu nedenle bu adımda yayın dalını master ile birleştirmemiz gerekir.

 $ git checkout master $ git merge --no-ff release/xyz $ git push

--no-ff bayrağı isteğe bağlıdır, ancak birleştirme hızlı ileri sarma tekniği kullanılarak tamamlanabilse bile yeni bir taahhüt nesnesinin oluşturulmasını zorlamak için kullanılması önerilir.

Ardından, sürümü ana dalda etiketlemenin zamanı geldi:

$ git tag -a xyz -m 'description of new version, features or fixes included'

Etiketler yararlıdır çünkü git deposunda geçmişteki bu belirli noktada ısrar ediyorsunuz ve belirli bir etiketten ayrı bir dal oluşturmak için daha sonra geri dönebilirsiniz.

3b. Serbest bırakma dalını birleştirmek için bir çekme isteği kullanın

Sıklıkla kullanılan başka bir alternatif, yayın dalını master ile birleştirmek için bir çekme isteği kullanmaktır.

Bu yaklaşımın sayısız avantajı vardır. Ekibin sürümle ilgili çeşitli sorunları tartışmak için kullanabileceği işbirliği için yeni bir alan oluşturulur. Bu nokta, tanıtılacak kodu izlemek ve olası değişiklikleri tartışmak için daha fazla göze sahipken, bir kod inceleme sürecini dahil etmek için fazladan bir geçit eklemek için iyi bir zamandır.

İş akışlarınıza çekme istekleri uygulamanıza izin veren bazı araçlar GitHub, Bitbucket ve GitLab'dır (ikincisinde istekleri birleştirme olarak adlandırılır). Bu araçlarla, git komutlarını manuel olarak yazmazsınız, bunun yerine kaynak dalı ( yayın ) ve hedef dalı ( master ) ayarlamak için bir web arayüzü kullanırsınız ve ardından bir veya daha fazla gözden geçiren eklersiniz; Bu yeni değişiklikler hakkında satır içi yorumlar yazabilir, iyileştirmeler önerebilir vb.

Tüm gözden geçirenler çekme talebini onayladıktan sonra, kullanıcı arayüzündeki bir düğmeye basarak değişiklikleri otomatik olarak ana ile birleştirebilirsiniz.

4. Master'ı Üretim Ortamına Dağıtın

Bu aşamada, uygulamayı dağıtmadan önce ekibinizdeki bir test kullanıcısının duman testi yapması (bu, ayrı bir kontrol listesinde tanımlanabilir) iyi bir uygulamadır. Ana dalı ayrı bir test ortamına dağıtmak iyi bir öneridir. Test cihazı, en son derlemede birleştirmeden sonra hiçbir şeyin yanlış gitmediğinden emin olmak için bazı temel eylemleri gerçekleştirebilir. Duman testi nasıl yapılır, bu makalenin kapsamı dışındadır, ancak web'de bununla ilgili birçok materyal bulabilirsiniz. Duman testinin sonucu, yanlış giden her şeyi belgeleyen yayın kontrol listesine/e-tabloya entegre edilebilir.

Bu noktada, değişiklikleri dağıtmaya ve bunları hayata geçirmeye hazırsınız. Devam edin ve ana şubeyi dağıtın. Bu adım, kullandığınız altyapı yığınına bağlı olacaktır. Uygulamanızı yüklemek için Amazon EC2 bulut sunucunuza bağlanmayı veya bir Heroku uzaktan kumandasına zorlamayı veya yeni sürümü kopyalamak için ssh aracılığıyla VPS'nize bağlanmayı veya başka bir işlemi içerebilir.

Uygulama yüklendikten sonra başarıyla dağıtıldığından ve beklendiği gibi çalıştığından emin olun.

5. Geliştirme ve Silme Sürümü Dalına Geri Dönün

Şimdi sürüm neredeyse tamamlandı, sürüm numarasını geliştirmek ve sürüm numarasını güncellemek ve yapılan tüm hata düzeltmelerini ana geliştirme şubesine aktarmak için sürüm dalını geliştirici ile birleştirmek isteyeceksiniz:

 $ git checkout develop $ git merge release/xyz

Şimdi sürüm dalını kaldırmanın zamanı geldi:

$ git branch -d release/xyz

6. Değişiklik Günlüğü Oluşturma

Projenizin kökünde CHANGELOG.md (veya eşdeğeri) adında bir dosya olmalıdır; burada, hata düzeltmeleri, yeni özellikler gibi içerdiği her şeyi belgelemek için yeni bir sürüm çıktığında yeni bir giriş eklemeniz gerekir. bilinen sorunlar ve sürüm notları biçimindeki diğer ilgili bilgiler. Bu, kullanıcıların ve katkıda bulunanların, projenin her bir sürümü (veya sürümü) arasında hangi değişikliklerin yapıldığını görmeleri için gerçekten yararlıdır .

Değişiklik günlüğü girişi, tarih, sürüm numarası ve sürümle ilgili bazı notları içerir. Girişler ters kronolojik sırada tutulmalıdır. İşte projenize uyarlayabileceğiniz, kullandığım basit bir şablon:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Ek olarak, bu adım, git günlüğünü geçen ve otomatik olarak değişiklik günlüğü girişini oluşturan temel bir komut dosyasını kodlayarak veya aynısını yapan bir araç kullanarak tamamen otomatikleştirilebilir, örneğin:

• Github Changelog Generator, skywinder tarafından,
• Fojuth tarafından ReadmeGen
• github değişiklikleri, lalitkapoor tarafından

Yine de, aldığınız otomasyon derecesinin, taahhüt mesaj formatınızın katılığı ile doğru orantılı olduğunu unutmayın. Ekiple taahhüt mesajları için belirli bir format üzerinde anlaşmanın her zaman iyi bir uygulama olduğuna inanıyorum. Taahhüt mesajlarının stiliyle ilgili yönergeleri izleyerek, ayrıştırmaları daha kolay olacak ve bu nedenle değişiklik günlüğünün oluşturulmasını otomatikleştirebilmeniz daha olası olacaktır.

7. Paydaşlarla İletişim Kurun

Burası genellikle aşağıdakilerden bazılarını yapacağınız yerdir:

• Yeni bir sürümün tamamlandığını dahili bir mesajlaşma aracı (örneğin: Slack) aracılığıyla ekibe bildirin. Yalnızca sürümle ilgili olayları iletmek amacıyla yeni bir kanal (yani: #releases ) oluşturmanızı öneririm. Bir eylem gerçekleştirildikten sonra bir mesaj göndermek için Slack kanalına kanca eklemek kolaydır.
• Alternatif olarak, değişiklik günlüğünün bağlantısını veya ekli değişiklik günlüğü dosyasını içeren bir e-postayı paydaşlara gönderin.
• Bir blog yazısı (uygulamanız veya ürününüz için bir blogunuz varsa) veya bir tweet yazın.

Kuruluşunuzun doğasına bağlı olarak daha fazla işlem yapılabilir. Önemli olan ürününüzün yeni bir versiyonunun mevcut olduğunu iletmeyi unutmamaktır.

8. Sorun İzleyicinin Bakımı

Bir sürüm yürütüldükten sonra, şu anda üretimde olan hata düzeltmelerini veya özellikleri takip etmek için muhtemelen bazı biletlerinizin durumunu güncellemeniz gerekecektir. Genel olarak bu, bazı etiketlerin değiştirilmesini içerir (küçük projeler için, yayın işlemi tamamlandıktan sonra kaldırdığım, yayın bekleyen bir etiket kullanırım).

Her yeni sürüm için kilometre taşları kullanırsanız, muhtemelen durumlarını güncellemeniz veya tamamlandı olarak işaretlemeniz gerekir. Hatta bazı sorun izleyiciler, sürümü planlamanıza ve sprintlerle uyumlu hale getirmenize, bir sürümün bir hatayı engelleyip engellemediğini ve diğer yararlı bilgileri izlemenize bile izin verir.

Her şey aracı nasıl kullandığınıza bağlıdır. Sorun izleyicideki bilgileri güncelleme görevinin sürüm kontrol listenize dahil edilmesi gerektiğini belirtmek isterim.

Yayın Sürecini Otomatikleştirme Hakkında

Okuyucu, yukarıda özetlenen değişiklik günlüğü adımı dışında, yukarıda bahsedilen adımların çoğunun da otomatikleştirilebileceğini fark etmiş olabilir.

Yayın sürecinin bazı bölümlerini otomatikleştirme yeteneği büyük bir kazançtır ve çok zaman kazandırır. Komut dosyaları oluşturmanızı veya bireysel adımları nasıl otomatikleştireceğinizi ve ardından sürekli bir teslim hedefine doğru nasıl çalışacağınızı bulmanızı öneririm. Sürekli teslim, riski azaltabilir, maliyetleri azaltabilir ve geliştiricilerin sürümü yönetmek için harcamaları gereken süreyi azaltabilir. Sonuç olarak, geliştirme için ayrılan saatler açısından daha sık yayın yapabilecek ve daha üretken olabileceksiniz.

DevOps şirketlerinin kutsal kâsesi, sürüm sürecini otomatik olarak tetikleyecek bir düğmeye basarak (veya bir komut çalıştırarak) yeni bir sürüm başlatabilmek veya daha da iyisi, yazılımınızın yeni bir sürümünü bir anda yayınlayacak bir sistem. belirlenmiş zaman. Tabii ki, bunu başarmak zordur çünkü ayrıca birçok test sürecini otomatikleştirmeniz gerekir, ancak bu imkansız değildir.

En İyi Uygulamaları Kucaklamak

Bu bölümde, ya sürüm sürecini daha sorunsuz hale getirmek ya da bir şeyler ters gittiğinde güvenlik önlemleri almak için uygun bulduğum birkaç önerilen uygulamayı anlatacağım.

Sürümü gerçekleştirmek için en uygun günü bulun

Üzerinde çalıştığım uygulamaları genellikle perşembe günleri öğlen ile iş kapanışı arasında yayınlarım.

Pazartesiden Cumaya kadar çalışıyorsanız, işe Cuma günü başlamak iyi bir fikir değildir. Yayınlandıktan sonra bir şeyler bozulursa, Pazartesiye kadar tamir etmeye vaktiniz olmayacak (hafta sonu çalışmak istemiyorsanız). Bu nedenle, yayınları Perşembe günü yapmak daha uygundur, çünkü dağıtıldıktan sonra yeni sürümü izlemek, sorunları gidermek veya geri almak için Cuma gününüz vardır.

Bir web uygulamasını yönetiyorsanız bahsetmeniz gereken bir diğer önemli nokta, kullanıcılarınızın çoğunun bulunduğu saat dilimini bilmektir. Bir şey başarısız olursa olası hasarı en aza indirmek için, trafiğin düşük olduğu bir dönemde yayına zaman vermelisiniz. Bazen, kullanıcı tabanınız tüm dünyaya yayıldığında bu zor olabilir, ancak yine de biraz araştırma yapmalı ve en iyi zamana karar vermelisiniz.

Yeni Bir Sürümden Önce Veritabanınızı Yedekleyin

DB'nizin planlanmış periyodik yedeklemeleri yoksa, sürüme başlamadan önce bir yedekleme gerçekleştirmek için sürüm sürecinize bir adım eklemenizi şiddetle tavsiye ederim.

Aşamalı Sunumlar

Bir yayıncı yeni bir özelliği kullanıma sunduğunu duyurduğunda, bu özelliğin telefonunuzda kullanılabilir hale gelmesinin neden günler, hatta haftalar sürdüğünü hiç merak ettiniz mi? Bunun nedeni, birçok şirketin aşamalı sunum kullanmasıdır.

Facebook bunu uzun süredir yapıyor. Yeni bir özelliği, kullanıcı tabanının yüzde 100'üne ulaşana kadar kademeli olarak artırarak, kullanıcılarının yüzde beş veya 10'unda test eder. Aşamalı sunum aşamasında, kullanıcı geri bildirimlerine ve kilitlenme raporlarına yakından bakmanız gerekir. Bu bilgilerle, her kullanıcıyı etkilemeden önce sürümü erteleyebilir veya hataları düzeltebilirsiniz.

Android'in Geliştirici Konsolunda, Android uygulamalarınız için aşamalı sunumlar uygulayan güzel bir araç var.

Sürekli Entegrasyon

Sürekli Entegrasyon, birçok nedenden dolayı benimsenmeye değer bir uygulamadır. İlk olarak, başarılı sürümlerin oranını artırarak hataları erken tespit etmenizi sağlar. İkinci olarak, daha önce açıklandığı gibi Sürekli Teslimat ve tam otomasyonu uygulamadan önceki ilk mantıklı adımdır.

Martin Fowler, Sürekli Entegrasyonun büyük bir savunucusudur. Bu uygulamayı kullanırken yayın sürecinize eklenebilecek çok sayıda avantajı açıklıyor. Bu geniş bir konu ve bununla ilgili birçok kitap ve blog yazısı var ve bundan burada bahsediyorum çünkü operasyonlarınızda size çok daha fazla güven vereceğine inanıyorum. CI kullanmanın birçok avantajı arasında şunları bulacaksınız: azaltılmış risk, neyin işe yarayıp neyin yaramadığını anlamak için artan görünürlük, hataların daha erken tespiti, artan dağıtım sıklığı ve daha fazlası.

CI'yi uygulamanın başlangıç ​​noktası, bir "sürekli entegrasyon sunucusu" kurmaktır; Denemek için bazı güzel araçlar şunlardır: CruiseControl, Bamboo, Jenkins ve Travis.

Exitlude: Her Şey İşe Yarayacak

Hepimiz oynadığımız rolü agresif bir şekilde savunuyoruz Ne yazık ki, seni yoluna göndermek için zamanlar geliyor Hepsini gördük, güven ateşleri, ani acılar seli Hiç önemli değil, merak etme, geçecek her şey yolunda

Çıkış, Katiller

Özetlemek gerekirse, karmaşıklığı, kullanıcı tabanı veya kuruluşunuzun ne kadar küçük olduğuna bakılmaksızın uygulamanız için iyi tanımlanmış bir yayın sürecine sahip olmanın çok önemli olduğunu söyleyebilirim.

Bunu yapmazsanız, bu kılavuzu ve benzerini kullanarak bazı temel adımlar üzerinde düşünmeye başlamanızı ve ilk taslağı bulmak için ekibinizle beyin fırtınası yapmanızı öneririm. Bir sonraki sürümünüzde deneyin, ardından yineleyin. Sonunda, kendi yayın sürecinizi oluşturmaya başlayacaksınız.

Bundan sonra , sürecin parçalarını nasıl otomatikleştireceğinizi düşünmeye başlayın. Geliştirilebilecek alanları düşünün. Küçük optimizasyonları birleştirerek yayın süresini azaltmanın yollarını keşfedin. Otomasyon nihai hedefiniz olmalıdır; ancak bunu baştan planlamayın, aksi takdirde böylesine büyük bir sıçramaya kalkışarak başarısız olursunuz. Her süreçte olduğu gibi, yavaş yavaş iyileştirmek daha iyidir.

Uygulamanızın yeni sürümlerini başlatmak için kullandığınız başka püf noktaları veya yönergeleriniz var mı? Eğer öyleyse, bana bildirin. DevOps dünyasından gelmiyorum, sadece oldukça organize ve yapılandırılmış bir geliştiriciyim, ancak birçok gazi ile karşılaştırıldığında, bu konuda hala acemiyim, bu yüzden yorum yapmaktan veya benimle iletişime geçmekten çekinmeyin. eklenecek bir şey.