GitLab'da yazılım düzeltmelerini iki şekilde işleriz: manuel ve otomatik olarak. Sürüm yöneticisinin önemli güncellemeleri oluşturma ve gitlab.com'a otomatik dağıtım yoluyla sunma işinin yanı sıra kullanıcıların kendi kurulumlarında çalışabilecekleri yamalar hakkında bilgi edinmek için okumaya devam edin.
Akıllı saatinize bir hatırlatıcı ayarlamanızı öneririm: Her ayın 22'sinde, tesislerinde GitLab ile çalışan kullanıcılar, ürünümüzün güncel sürümüne ilişkin güncellemeleri görebilir. Aylık sürüm, yeni özellikleri ve mevcut özelliklerdeki gelişmeleri içerir ve sıklıkla topluluk araçları veya birleştirme taleplerinin nihai sonucunu gösterir.
Ancak uygulamanın gösterdiği gibi, yazılım geliştirme nadiren kusursuzdur. Bir hata veya güvenlik açığı keşfedildiğinde dağıtım ekibindeki sürüm yöneticisi, kullanıcılarımıza kurulumlarıyla birlikte bir yama oluşturur. Gitlab.com CD işlemi sırasında güncellenmektedir. GitLab'daki CD özelliğiyle karışıklığı önlemek için bu CD işlemine otomatik dağıtım adını veriyoruz. Bu süreç, kullanıcılar, müşteriler ve dahili geliştirme ekibimiz tarafından gönderilen çekme taleplerinden gelen önerileri içerebilir, böylece yamaların yayınlanmasıyla ilgili sıkıcı problemin çözümü iki farklı şekilde çözülür.
«Geliştiricilerin yaptığı her şeyin GitLab.com'a sunulmadan önce her gün tüm ortamlara dağıtılmasını sağlıyoruz.", açıklıyor , Kıdemli Teknik Müdür, Altyapı Departmanı. "Kurulumlarınızın sürümlerini gitlab.com dağıtımlarının anlık görüntüleri olarak düşünün; kullanıcılarımızın kurulumlarında kurulum yapmak için kullanabilmeleri amacıyla bir paket oluşturmak için ayrı adımlar ekledik.'.
Hata veya güvenlik açığı ne olursa olsun, gitlab.com müşterileri düzeltmeleri yayınlandıktan kısa bir süre sonra alacaktır; bu da otomatik CD sürecinin bir avantajıdır. Kendi kurulumlarına sahip kullanıcılara yönelik yamalar, sürüm yöneticisi tarafından ayrı bir hazırlık gerektirir.
Teslimat ekibi, sürümlerin oluşturulmasında yer alan süreçlerin çoğunu otomatikleştirmek için çok çalışıyor. (üretime kadar geçen ortalama süre, yani üretim için harcanan süre), bir geliştiricinin birleştirme isteğinin işlenmesinden gitlab.com'da dağıtıma kadar geçen süre.
«Teslimat ekibinin amacı, şirket olarak daha hızlı hareket edebilmemizi sağlamak veya en azından teslimatçıların daha hızlı çalışmasını sağlamaktır, değil mi??, diyor Marin.
Hem gitlab.com müşterileri hem de kurulumlarının kullanıcıları, dağıtım ekibinin döngü sürelerini kısaltma ve dağıtımları hızlandırma çabalarından yararlanır. Bu yazımızda bu iki yöntem arasındaki benzerlikleri ve farklılıkları açıklayacağız. Ayrıca dağıtım ekibimizin kendi tesislerinde çalışan kullanıcılar için yamaları nasıl hazırladığını ve otomatik dağıtım kullanarak gitlab.com'un güncel olmasını nasıl sağladığımızı da açıklayacağız.
Sürüm yöneticisi ne iş yapar?
Ekip üyeleri aylık Sürümler arasında oluşabilecek yamalar ve güvenlik sürümleri de dahil olmak üzere, kullanıcıların tesislerindeki sürümlerimizi kullanıcılara sunuyoruz. Ayrıca şirketin otomatik, sürekli dağıtıma geçişine liderlik etmekten de sorumludurlar.
Marin, kendi kendine kurulum sürümleri ve gitlab.com sürümlerinin benzer iş akışlarını kullandığını ancak farklı zamanlarda çalıştıklarını açıklıyor.
Her şeyden önce sürüm yöneticisi, sürüm türü ne olursa olsun, uygulamanın gitlab.com'da başlatıldığı andan itibaren GitLab'ın kullanılabilir ve güvenli olmasını sağlar ve aynı sorunların müşterilerin altyapılarında da yer almamasını sağlar. kendi kapasiteleri.
GitLab'da bir hata veya güvenlik açığı düzeltildi olarak işaretlendiğinde sürüm yöneticisi, bunun kullanıcıların kurulumlarıyla birlikte yamalara veya güvenlik güncellemelerine dahil edilip edilmeyeceğini değerlendirmelidir. Bir hatanın veya güvenlik açığının güncellemeyi hak ettiğine karar verirse hazırlık çalışmaları başlar.
Sürüm yöneticisi, bir düzeltmenin hazırlanıp hazırlanmayacağına veya ne zaman dağıtılacağına karar vermelidir ve bu büyük ölçüde durumun bağlamına bağlıdır, "Bu arada makineler bağlamı yönetme konusunda insanlar kadar iyi değil" diyor Marin.
Her şey düzeltmelerle ilgili
Yamalar nedir ve neden onlara ihtiyacımız var?
Sürüm yöneticisi, hatanın ciddiyetine göre bir düzeltmenin yayınlanıp yayınlanmayacağına karar verir.
Hatalar ciddiyetine göre değişir. Dolayısıyla S4 veya S3 hataları, piksel veya simge yer değiştirmesi gibi biçimsel olabilir. Bu daha az önemli değil, ancak kimsenin iş akışı üzerinde önemli bir etkisi yok, bu da bu tür S3 veya S4 hataları için bir düzeltme oluşturulma olasılığının düşük olduğu anlamına geliyor, diye açıklıyor Marin.
Ancak S1 veya S2 güvenlik açıkları, kullanıcının en son sürüme güncelleme yapmaması gerektiği veya kullanıcının iş akışını etkileyen önemli bir hatanın olduğu anlamına gelir. İzleyiciye dahil edilmişlerse, birçok kullanıcı bunlarla karşılaşmıştır, bu nedenle sürüm yöneticisi hemen bir düzeltme hazırlamaya başlar.
S1 veya S2 güvenlik açıklarına yönelik bir yama hazır olduğunda, sürüm yöneticisi yamayı yayınlamaya başlar.
Örneğin GitLab 12.10.1 yaması, çeşitli engelleme sorunları tespit edildikten ve geliştiriciler bunlara neden olan temel sorunu düzelttikten sonra oluşturuldu. Sürüm yöneticisi, atanan önem düzeylerinin doğruluğunu değerlendirdi ve onayın ardından, engelleme sorunlarının keşfedilmesinden sonra XNUMX saat içinde hazır olan bir düzeltmeyi yayınlama süreci başlatıldı.
Çok sayıda S4, S3 ve S2 biriktiğinde sürüm yöneticisi, bir düzeltmenin yayınlanmasının aciliyetini belirlemek için bağlama bakar ve belirli bir sayıya ulaşıldığında hepsi birleştirilir ve yayınlanır. Sürüm sonrası düzeltmeler veya güvenlik güncellemeleri blog gönderilerinde özetlenmiştir.
Bir sürüm yöneticisi yamaları nasıl oluşturur?
Yamalar oluşturmak için GitLab CI'yı ve ChatOps gibi diğer özellikleri kullanıyoruz. Sürüm yöneticisi, dahili kanalımızdaki ChatOps ekibini etkinleştirerek düzeltmenin yayınlanmasını tetikler #releases Slack'te.
/chatops run release prepare 12.10.1ChatOps, farklı olayları tetiklemek için Slack içinde çalışır ve bunlar daha sonra GitLab tarafından işlenir ve yürütülür. Örneğin dağıtım ekibi, yamaları yayınlamak için çeşitli şeyleri otomatikleştirmek üzere ChatOps'u kurdu.
Sürüm yöneticisi Slack'te ChatOps ekibini başlattıktan sonra işin geri kalanı GitLab'da CICD kullanılarak otomatik olarak gerçekleşir. Sürüm yöneticisi süreçteki bazı önemli adımları etkinleştirdiğinden, sürüm süreci boyunca Slack'teki ChatOps ile GitLab arasında iki yönlü iletişim vardır.
Aşağıdaki video GitLab için yama hazırlamanın teknik sürecini göstermektedir.
Gitlab.com'da otomatik dağıtım nasıl çalışır?
Gitlab.com'u güncellemek için kullanılan süreç ve araçlar, yama oluşturmak için kullanılanlara benzer. Gitlab.com'u güncellemek, sürüm yöneticisi açısından daha az manuel çalışma gerektirir.
Dağıtımları ChatOps kullanarak çalıştırmak yerine CI özelliklerini kullanıyoruz; , sürüm yöneticisinin belirli eylemleri gereken zamanda gerçekleştirilecek şekilde planlayabilmesini sağlar. Manuel bir süreç yerine, saatte bir periyodik olarak çalışan, GitLab projelerinde yapılan yeni değişiklikleri indiren, bunları paketleyen, dağıtımı planlayan ve testi, QA'yı ve diğer gerekli adımları otomatik olarak çalıştıran bir işlem hattı vardır.
Marin, "Dolayısıyla, gitlab.com'dan önce farklı ortamlarda çalışan çok sayıda dağıtımımız var ve bu ortamlar iyi durumda olduktan ve testler iyi sonuçlar gösterdikten sonra sürüm yöneticisi, gitlab.com dağıtım eylemlerini başlatır" diyor.
Gitlab.com güncellemelerini desteklemeye yönelik CICD teknolojisi, sürüm yöneticisinin üretim ortamının gitlab.com'a dağıtımını manuel olarak başlatması gereken noktaya kadar tüm süreci otomatikleştirir.
Marin, aşağıdaki videoda gitlab.com güncelleme sürecini ayrıntılarıyla anlatıyor.
Teslimat ekibi başka ne yapar?
Gitlab.com güncelleme süreçleri ile yamaların şirket içinde müşterilere yayınlanması arasındaki temel fark, ikinci sürecin sürüm yöneticisinin daha fazla zaman ve daha fazla manuel çalışma gerektirmesidir.
Marin, "Bildirilen sorunlar, araç sorunları ve tek bir yama yayınlanırken dikkate alınması gereken birçok nüans olması nedeniyle bazen yamaları müşterilere kurulumlarıyla birlikte yayınlamayı geciktiriyoruz" diyor.
Teslimat ekibinin kısa vadeli hedeflerinden biri, sürüm yöneticisinin sürümü hızlandırmak için yaptığı manuel iş miktarını azaltmaktır. Ekip, düşük önem derecesine sahip sorunların (S3 ve S4) düzeltilmesine yardımcı olacak sürüm sürecini basitleştirmek, kolaylaştırmak ve otomatikleştirmek için çalışıyor. yakl. çevirmen). Hıza odaklanmak önemli bir performans göstergesidir: MTTP'yi (birleştirme isteğinin alınmasından sonucun gitlab.com'a dağıtılmasına kadar geçen süre) mevcut 50 saatten 8 saate düşürmek gerekir.
Teslimat ekibi aynı zamanda gitlab.com'u Kubernetes tabanlı bir altyapıya geçirmek için de çalışıyor.
Editörün n.b.: Kubernetes teknolojisini zaten duymuşsanız (ve duyduğunuza hiç şüphem yok), ancak henüz dokunmadıysanız, çevrimiçi yoğun kurslara katılmanızı öneririm. 28-30 Eylül tarihlerinde gerçekleştirilecek olan ve 14-16 Ekim'de gerçekleşecek. Bu, teknolojiyle güvenle gezinmenize ve çalışmanıza olanak tanır.
Bunlar aynı hedefi güden iki yaklaşımdır: güncellemelerin hem gitlab.com için hem de müşteriler için tesislerindeki hızlı teslimatı.
Bizim için herhangi bir fikir veya öneriniz var mı?
Herkes GitLab'a katkıda bulunabilir ve okuyucularımızdan gelen geri bildirimleri memnuniyetle karşılarız. Teslimat ekibimiz için herhangi bir fikriniz varsa tereddüt etmeyin işaretli team: Delivery.
Kaynak: habr.com