Çok taraflı bir projede sürüm oluşturmayı nasıl ele alırsınız?

Bunun geniş bir soru olduğunu biliyorum, bu yüzden mümkün olduğunca spesifik olmaya çalışacağım. Bu soru teknik bir sorudan ziyade "örgütsel" bir sorudur.

Bu ana bileşenlerle çok taraflı bir projemiz var:

• Temel iş mantığını barındıran bir sunucu (veri modelleri)
• Temel iş mantığını kullanan müşteriler için bir backoffice
• Temel iş mantığını da kullanan bir uygulama API'sı (REST)
• Uygulama API'sını kullanan akıllı telefon uygulamaları (iOS ve android) var
• Aynı uygulama API'sını kullanarak akıllı telefondan farklı bir tablet uygulaması (android) var.

Yakında aktif müşterilerle üretimde olacağım. Ve herhangi bir proje olarak, zaman içinde tüm farklı bileşenleri korumam gerekecek. Bu, aşağıdakilerin hepsinin yükseltilebileceği anlamına gelir:

• sunucudaki temel iş mantığının kodu (arka ofis, API ve yan etki olarak mobil uygulamalar tarafından kullanılır)
• API'nın kendisi (hem akıllı telefon hem de tablet uygulamaları tarafından kullanılır)
• tüm mobil uygulamalar (appstore / googleplay üzerinden)

Tabii ki, sunucu tarafı parçalar (temel iş mantığı kodu ve API kodu) hemen kendim değiştirilebilir. Ancak, yeni mobil uygulamaların appstore / googleplay'daki istemciler tarafından indirilmesi gerekir ve bunların güncel olduğundan emin olamıyorum.

Tez yükseltmelerini sorunsuz ve müşteri için risksiz hale getirmek için herhangi bir rehberlik, iyi uygulama ipuçları verebilir misiniz?

"Bileşene" geçmek için hangi bileşene ihtiyacım var? İstemci mobil uygulamasını yükseltmese bile her şeyin nasıl çalıştığından nasıl emin olabilirim? İşimi kolaylaştırmak için onu yükseltmeye zorlamalı mıyım?

Tek kelimeyle, çok taraflı projemi zaman içinde canlı hale getirmek için nasıl organize etmeliyim?

Mobil uygulamaların ne zaman yeni bir sürüme güncelleneceğini kontrol edemeyeceğiniz için, en azından REST API'nizi sürümlendirmeniz gerekir. Bunu yapmazsanız, o arayüzde geriye dönük olarak uyumsuz değişiklikler yapmak imkansız olacaktır.

REST API'sinin yanı sıra, bir ağ arayüzü üzerinden geçen diğer iletişim arayüzlerini de versiyonlamak iyi bir fikirdir. Bu şekilde, tüm backoffice istemcilerini sunucularla aynı anda yükseltmek zorunda kalmazsınız ve "beta testi" dönemiyle yeni bir sürüme aşamalı geçiş uygulayabilirsiniz.

İletişim arayüzlerini versiyonlamanın yanı sıra, değişiklikleri mümkün olduğunca geriye doğru uyumlu hale getirmeye çalışmalısınız. İdeal olarak, eski istemcileri hala tam olarak destekleyen yeni bir arayüz sürümü sunabilir, böylece hiçbir şeyin değiştiğini fark etmezler.

Bu gönderi sorunuz hakkında ilginç bir noktaya değiniyor.

Daha pratik bir şekilde, 3 bileşeniniz varsa:

• 2 Tüketiciler: Bir Ön Uç ve Mobil Uygulama
• 1 API sağlayıcısı: bir Arka Uç

Her biri için tipik Mmp (Major.minor.patch) sürüm şemasını kullanabilirsiniz, ancak Arka Uç URL'nizde bir şey koyabilirsiniz http://youhost/M.m/resourceURI.

Siz geliştikçe ve API'deki değişiklikler M.mURL'de olduğu gibi sakladığınız tüketicilerle olan sözleşmenizi etkilemez . Andan itibaren size tüketicileri etkileyen arka uç bir değişiklik yapmak, bir kullanma (Bu davranış ya da farklı bir nesnede değişiklik olması) M.m+1, M+1.m+1veya M+1.m.

Kullanıcıların yeni tüketicileri yüklerken ve eski API'yı yavaşça bırakırken, işleri arkada tutmanın yolu yeni Arka Uç'u eskisiyle eşzamanlı olarak dağıtmaktır.

Burada benimkinden daha iyi bir cevap görebilirsiniz: Stackoverflow üzerinde REST API'yi Sürümlendirme

Sürekli bir tümleştirme sunucusu yüklemenizi, kod deponuza ve anlık görüntü / yayın deposuna bağlamanızı ve yapılarınızı otomatikleştirmenizi öneririm. Bunun bir takım avantajları olacaktır:

1. Her bileşen piyasaya sürüldüğünde sürümlendirilecektir. Bu, son ürünlerinizin yanı sıra düşük seviyeli kütüphaneleri de içerir.
2. Her kod taahhüdü bir anlık görüntü derlemesini tetikler. Bu, özellikle tesisi, inşaatı bozan suçluya e-posta göndermek için kullanıyorsanız, geliştiricilerinizi dürüst tutmaya yardımcı olur.
3. Her yapı birim testleri yapabilir. Bu, kod kalitesini önemli ölçüde artırır.
4. Her sürüm etiketlenecektir, bu nedenle bir üretim düzeltmesi gerekiyorsa, etiketten dallamak ve düzeltmeyi yapmak kolaydır.
5. Bir çeşit uyumluluk kaydı tutmanız gerekecektir. (örn. BackOffice 1.0.23, REST API 2.0.267 vb. ile uyumludur). Bu alanda yardımcı olacak bir araç bilmiyorum.

Deneyimim açık kaynak araçlarla oldu: SVN, Maven 2, Jenkins ve Nexus, ancak bunların hepsine alternatifler var.

Takımınızı hızlandırmak için öğrenme süresini hafife almayın. Ama hız kazandıktan sonra, asla geri dönmeyecekler.

Geliştirme ve dağıtım için nispeten küçük bir ekip için, IBM Jazz tarafından kullanılan İstemci N-1 uyumluluk modeli oldukça iyi çalışabilir

İstemcileri ve sunucuları aynı sürüm numarasında tutmaya çalışın . [Bağımsız versiyonlar matrisini ve uyumluluklarını yönetmek yerine]

İstemci sürüm Xyy'nin Xyy'nin üstündeki ancak X + 2.0.0'dan daha düşük olan tüm sunucu sürümleriyle çalışması gerektiğini ilke edin

Bir sunucu sürümü 4.0 için, ideal olarak her istemci türü için bir istemci sürümü 4.0 olmalıdır. Ancak, istemcilerin ve sunucuların biraz farklı sürümlerine izin verecek şekilde uyumluluk korunmalıdır.

İstemci sürüm 4.x, sürüm 4.x ve üstü, ancak 6.0'ın altı sunucularla uyumlu olmalıdır; Sunucu 4.x, tüm istemciler sürüm 3.0 ve üstü ile uyumlu olmalı, ancak 4.x veya daha az olmalıdır

Bu şekilde, istemcilerin yeni sürümlerinin hemen yayınlanmasından endişe etmeden sunucudaki bir sürümü güncelleyebilirsiniz, ancak yalnızca iyi tanımlanmış bir uyumluluk penceresine sahip olacaksınız.

Ref: IBM Caz Modeli [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

İlk olarak, sorunu biraz farklı bir şekilde çerçeveleyerek başlayalım. "Yazılım" için hangi yazılım parçalarına ihtiyacınız olduğunu sordunuz. Sürüm, CS'de aşırı yüklü bir terimdir ve yaklaşık 100 farklı anlama gelebilir. Bakacağım başlıca şeyler:

1. Sürüm Kontrolü - Sürüm kontrolü, anlık görüntüleri ve gelişiminizin geçmişini takip etmenize yardımcı olan bir yapılandırma yönetimi aracıdır. TÜM KOD SÜRÜM KONTROLÜ ALTINDA OLMALIDIR. Sadece bin klasörünüze eklediğiniz kolaylık komut dosyaları olup olmadığını umursamıyorum, zaman yazmaya değer olan her şey bir revizyon kontrol yazılımına eklemek için iki saniyeye değer.
2. Yapılandırma Yönetimi - Derlemede ne olduğunu nasıl kontrol ederim. Tüm yazılımların bir dereceye kadar konfigürasyon yönetimi olmalıdır. Sürüm kontrolü geliştirme geçmişini izlemek için bir araç olduğu için, yöneticilere sürüm kontrolü ve konfigürasyon yönetimi arasındaki farkı tanımlamak isterken, konfigürasyon yönetimi geçmişi nasıl oluşturduğumuza ve koda karar vermek gibi şeyleri nasıl yaptığımıza ilişkin yönergelerdir. iyidir.
3. Yazılım sürüm oluşturma - kod sürümlerine ad atama. Bu, birçok insanın sorunu ilk gördüklerinde takıldığı şeydir, çünkü "MineSweeper 7.1.29290149210" ya da satın aldıkları şeylerde ne olursa olsun, ama dürüst olmak gerekirse bunu çok daha büyük bir sorunun en küçük kısmı olarak görüyorum. Dürüst olmak gerekirse, sadece 1'in ürettiği hash'i kullanmak ve insan tarafından okunamayacağı kadar iyi değil.

Bu yüzden benim için en belirsiz ve en ilginç olduğu için sadece # 2'ye odaklanacağım. Konfigürasyon yönetimi için tek bedene uyan, çerez kesici bir çözüm yoktur. 2 veya 3 kişilik bir ekip için iyi çalışan kurallar, yüzlerce işçiyi alan bir projede akıl sağlığını korumak için çok gevşek olabilir. Büyük ekiple çalışan kurallar, küçük ekip için çok fazla ek yük gerektirebilir. Büyük olasılıkla, bir şeyleri bir araya getirmek için kendinize ait bir şeyle uğraşmanız gerekecek, ancak aşağıdaki listeyi yapılandırma yönetimi sisteminizin özelliklerini geliştirmenin bir yolu olarak kullanacağım:

1. Pazar yerinde desteklediğim sürümleri (ve bunlarla ilişkili sorunları) nasıl takip edebilirim?
2. Hangi geliştirme yollarının üretim sistemlerine bırakılmaya hazır olduğuna nasıl karar vereceğim? (Bir süreçteki diğer herhangi bir adım için de hazır olabilir)
3. Sistem yapılandırmasını kim kontrol etmeli / yönetmelidir? Diğer geliştiricilere dağıtılacak kod eklemek için iş akışı nedir?
4. Etkileşen parçalar arasındaki etkileşimi nasıl kontrol edeceğim? Bir parçayı değiştirmenin sistemin geri kalanını bozup bozmayacağını nasıl bileceğim?
5. Zaman içinde konfigürasyon yönetim sistemimizi nasıl geliştireceğiz.

Yukarıdaki soruları cevaplamak için yardıma mı ihtiyacınız var? Muhtemelen bir danışman ya da yazılım mühendisliği müdürü kiralamalısınız.