Gruptaki on binlerce uygulama ve Ar-Ge personelinin günlük çalışmalarını, Ali'nin sürekli teslim platformunun tasarımını ve yinelemesini üstlenmek
Yazar Chen Xin (Shenxiu)
Düzenle Xiaozhi
Alibaba'nın sürekli teslimat platformu 8 yıllık sürekli yinelemeli evrim geçirdi ve grubun on binlerce uygulaması için en önemli Ar-Ge aracı haline geldi.Verimliliği, on binlerce Ar-Ge'nin günlük çalışmasını doğrudan etkiliyor. Ancak platform yalnızca bir araç yığını değil, aynı zamanda derinlemesine düşünmeyi ve İnternet çağının araştırma ve geliştirme modelini sürekli olarak geliştirmeyi gerektirir ve mühendis kültürünü ve mühendislik uygulamalarını sürekli olarak ona entegre eder. Işık kontrolü ve ağır teknoloji, endüstrideki en son mühendislik uygulamalarını kullanın ve teknisyenlerin verimlilik sorunlarını çözmek için teknolojinin evrimini kullanın. Bu konuşma, Ali'nin sürekli dağıtım araçlarının gelişimini ve İnternet endüstrisinin dağıtım alanındaki sıcak konuların düşünme ve uygulamalarını tanıtacak.
Not: Bu makale, Alibaba kıdemli teknik uzmanı Chen Xin (Shenxiu) tarafından ArchSummit Global Architect Summit 2017 Shenzhen Station'da yapılan bir konuşmadan derlenmiştir. Orijinal başlık "İnternet Çağında Sürekli Teslimat" dır.
Önüne yaz
Herkese merhaba, ben Alibaba'nın meşhur şovundan geliyorum, bugün sizlere getirdiğim konu internet çağında sürekli teslimat. Sürekli dağıtımdan önce İnternet neden vurgulanmalı? Ali'nin sürekli teslimat uygulamasının özelliği nedir? Umarım burada bazı fikirler sunabilirim ve size biraz kazanç sağlayabilirim.
Alibaba'da sürekli teslimat platformunun ve Ar-Ge araç zincirinin inşasından ve ilgili yeteneklerin Alibaba Cloud aracılığıyla üretilmesinden sorumluyum. Harici sürümümüz Yunxiao olarak adlandırılıyor ve genel bulut şu anda genel beta sürümündedir.
Tamam, konuya girelim.Önce size bugünün ana içeriğini tanıtacağım.
-
Her şeyden önce, Ali'nin sürekli teslimat araçlarının yıllar içindeki gelişimine ve inşaat fikirlerimiz üzerine odaklanacağım.
-
Daha sonra, İnternet kurumsal ürünlerinin hızlı gelişimi altında önemli bir konuyu sizinle tartışacağım: kalite ve verimlilik ve ikisi arasındaki ilişkiyi nasıl gördüğümüzü ve nasıl koordine edileceğimizi tanıtacağım.
-
Bir diğeri de karşı karşıya olduğumuz sorun: teslimat ve geliştirme Geleneksel yazılım şirketleri kesinlikle teslimata yabancı değiller, ancak Ali senaryosunda bazı yeni zorluklarla karşılaşacağız. Devops, ilerlememizi ve geçen yılki küçük bir yeniliği tanıtıyor.
Geliştirme: Ali'de sürekli teslimat
zaman çizelgesi
İlk olarak Ali'nin sürekli dağıtım platformunun geliştirme sürecini tanıtın: ilk aşama 2009 yılında, SCM ve PE öğrencilerinin tek nokta problemini çözmek için basit bir otomatik yayınlama aracı yaptık. Bundan önce, pek çok şirket bu süreçten geçmiş olabilir. Belli bir zamanda bir sürüm başvurusu gönderdiler ve boru tesisatı sınıf arkadaşları kod paketini dondurmaya başladı ve ardından yayınlanması için işletim ve bakım sınıf arkadaşlarına teslim etti. Küçük ekipler ve küçük işletmeler için zar zor yeterli. Uygulama ölçeği büyüdükçe ve çevrimiçi ortam gittikçe daha karmaşık hale geldiğinde, boru tesisatı ve işletme ve bakım becerisi ve verimliliği, ürünlerimizin geliştirilmesini engellemeye başlar. Tabii ki, acil durum anonsu yapmak için gezintiye çıkmak ve korsan sınıf arkadaşlarından kahve içmelerini istemek gibi bazı yolsuzluklar da var. şaka yapıyorum.
İki yıl içinde, gittikçe daha fazla Ar-Ge personeli, çeşitli karmaşık Ar-Ge özellikleri, çeşitli çevrimiçi karmaşık komut dosyaları ve çukur kazan çeşitli yeni öğrenciler ve çukurlara adım attı. Tüm bunlar standartlaştırılmalıdır. Daha sonra, 2013'te kod değişikliğini çevrimiçi sürümle tamamen birleştirdik ve birleşik bir inşaat ve dağıtım platformu aracılığıyla sıkı bir şekilde kontrol ettik.
Açıkçası bu yeterli olmaktan uzak. 2016'da platform yeniden yükseltildi. Gereksinimlerden koda, teslimattan geri bildirime kadar tek noktadan bir platform başlatıldı. Projeler, gereksinimler, kodlar, yapım, test, sürüm, boru hattı, kamuoyu geri bildirimi vb. Ve ürünün büyük resmi temelde tamamlanmıştır.
2017 yılında, bu 8 yıllık platform aracı deneyimini, bulut verimliliğinin ürünü olan Alibaba Cloud'a açtık.Alibaba'nın deneyimiyle bulut ekolojisini geri beslemeyi ve aynı zamanda araçlarımızın büyümesine yardımcı olmak için geliştiricilerin deneyimlerine güvenmeyi umuyoruz.
Araçlar ve konsept gelişimi
Geliştirme sürecinden bahsettikten sonra, araç ve konseptlerimizin gelişim sürecini tanıtalım.Aşağıda bu dört noktaya ayrıntılı olarak odaklanacağız.
Birincisi otomasyon, Otomasyon, araçların önce başarması gereken değerdir ve aynı zamanda verimliliği artırmanın en doğrudan yoludur. Bizim için öncelikle konfigürasyon, kod, test, operasyon ve bakım otomasyonunu tamamlayacağız.
İkincisi standartlaştırmadır. Standardizasyon, araç platformunun en büyük misyonudur. Örneğin, Amazon'un sık sık bahsettiği Apollo ortam dağıtım aracı çok iyidir. Alibaba ayrıca kendi Ar-Ge standartlarına ve işletim ve bakım standartlarına sahiptir. Ar-Ge standartları Ar-Ge modu, teknoloji yığını ve yapılandırmayı içerir. Yönetim standartlarının yapılması nispeten kolaydır. Etki alanlarını işletmek ve sürdürmek oldukça zordur.Şu anda web uygulamaları, mobil uygulamalar, arama, sistem temel yazılımları vb. Kendi sistemlerini oluşturacak ve iç grup ve Alibaba Cloud da biraz farklı olacaktır. Ancak kapsayıcıya alma ve birleştirilmiş zamanlamadaki ilerlemeyle, bunların birleştirilmesi bekleniyor.
Üçüncüsü, özelleştirmedir. Özelleştirme, platform için daha yüksek bir gereksinim olmalıdır. Farklı ekipler ve farklı beceri seviyeleri, doğal olarak farklı araçlara ihtiyaç duyar. Kontrol nedeniyle esnekliği kaybedemeyiz ve düşük seviyeli becerilere dikkat ederek yüksek seviyeleri sınırlayamayız. Bu nedenle, öncelikle ekibin olgunluğuna göre uygun teslimat süreçleri ve yönetim uygulamaları önereceğiz.
Dördüncüsü tek durak noktasıdır.Araçlar çiçek açmaya başladığında, bu Ar-Ge öğrencileri için zararlı olacaktır.Farklı etkileşimler ve farklı ürün yerleştirme biçimleri yalnızca sistemin karmaşıklığını artırmakla kalmaz, aynı zamanda platformlar arasındaki akışın verimliliğini de azaltır. . Bu nedenle, talepten geri bildirime kadar tüm bağlantıyı açmak ve tek bir platformda değer temelli teslimatı tamamlamak için platform aracı entegrasyonunu kullanıyoruz.
Her şeyi otomatikleştirin
Şimdi ilk fikrimize bir göz atalım: her şeyi otomatikleştirmek. Bu resim, ortak bir Ar-Ge sürecini göstermektedir. İlk olarak geliştirme dalını geliştirme için ana bölümden alıyoruz, yayınlanmak üzere sürüm dalında birleştiriyoruz ve sürüm tamamlandıktan sonra ana olarak birleştiriyoruz. Her Ar-Ge ekibinin dallanma sorunlarıyla başa çıkmak için kendi spesifikasyonları olmalıdır. Ekibin boyutu büyüdüğünde veya yeni gelenler ortaya çıktığında, operasyonların nasıl standartlaştırılacağı, işbirliği verimliliğinin nasıl artırılacağı ve hataların nasıl önleneceği, tüm bunları taşıyacak araçlara ihtiyaç duyulur.
Birkaç ortak Ar-Ge modumuz var: ana hat geliştirme, şube geliştirme, gitflow, vb. Dal çekmeden başlayarak, birleştirme isteğinin beyaz ekran çözünürlüğüne, kod birleştirme, çakışma çözümüne ve nihayet bir ardışık düzen olarak basitleştirilmesine kadar, yeni bir geliştiricinin yalnızca platformda olması gerekir Operasyon, araştırma ve geliştirme çalışmalarına hatasız olarak anında entegre edilebilir.
Standardizasyon
Standardizasyon yönüne bakıldığında, araç seviyesi esas olarak şu yönleri tamamlar: uygulama oluşturma, test ve kabul, standart ortam, çevrimiçi takılıp kalan noktalar ve dağıtım süreci.
Uygulama, bir kod tabanına ve bir hizmet birimine karşılık gelir.Kod önerileri ve springboot promosyonu gibi teknoloji yığını şablonları aracılığıyla grup standartlarının uygulanmasını ve yinelemesini gerçekleştiririz. Kaynak planlaması yoluyla altyapının uygulamasını ve inşasını hızla tamamlayın.
Test kabulü açısından, grup protokolü ve güvenlik testi, son birkaç yılda teşvik edilen ana standartlardır ve tüm grupta uygulanmaktadır.Kod kalite puanı, veri ölçümü yoluyla mevcut uygulama kalitesinin objektif bir değerlendirmesidir.
Standart ortam, teslimat boru hattının ve operasyon ve bakım yönetimi ve kontrolünün temelidir.Şimdi, konteynırlaştırma ve birleşik programlama yoluyla nispeten kolay bir şekilde uygulanabilir. Dördüncü nokta daha ilginçtir. Aracın orijinal fikri, genellikle dağıtım ve kaynak sorunlarının, kullanıcıları günlükleri temizleme ve makineleri yeniden başlatma gibi otomatik araçlar aracılığıyla kendi kendilerine çözmeye yönlendireceğidir. Artık daha fazla kendi kendini iyileştirme yöntemleri benimseyecek, çevresel kaynak işletim ve bakım çalışmalarını insan müdahalesi olmadan platforma yerleştireceğiz ve insanları araçlarla değiştireceğiz.
Çevrimiçi olarak sıkışan noktalar, çoğunlukla, Ar-Ge davranışını ve kalitesini kontrol etmek için grubun birleşik yönetim ve kontrol stratejisine dayanan yönetim ve kontrol gereksinimleridir.
Son dağıtım sürecinde, sürüm stratejisi, izleme, temel ve geri alma gerekli işlevlerdir, bu nedenle burada tekrar etmeyeceğim.
Özelleştirilmiş çözümler
Özelleştirme elde etmek için önce çözümün birkaç faktörüne bakın:
Takım olgunluğu: Ölçek nedir, 1-2 kişi, 7 kişi, 10 veya daha fazla kişi? Tam yığın için bağımsız bir test işletimi ve bakım ekibi var mı? Kalite nedir ve herhangi bir teknik borç var mı? Ekip içindeki özel normlar ve kurallar nelerdir?
Yinelemeli hız: her gün her zaman? Yoksa periyodik olarak mı teslim ediliyor? Sürekli teslimat perspektifinden bir pencere kısıtlaması olsun ya da olmasın, çevrimiçi davranışı çok fazla kısıtlamak istemiyoruz ve kart noktasını karşılıyorsa çevrimiçi olmalıdır.Alibaba'nın temel uygulamaları temelde herhangi bir zamanda, hatta günde birkaç kez yayınlanır.
BU teknoloji yığını: İlgili BU'lerinin bazı özel mal özellikleri ve kişiselleştirilmiş farklılıklar. Birleşik bir altyapı ve Ar-Ge operasyon ve bakım platformu inşa ediyor olsak da, hala% 100 birleşme sağlayamıyoruz, üzerinde çalıştığımız yön budur.
Sonuncusu entegre teslimat: Ürün entegrasyon gereksinimleri ve proje teslimi var mı? Veya tescilli bulut teslimi. Tipik olanlar e-ticaret, mobil ve Alibaba Cloud'dur.
Bu dört faktörden birkaç özelleştirme yönü elde ettik:
Ar-Ge modu: Küçük ölçekli ekipler, uygulamalara dayalı olarak şube Ar-Ge'sini benimser, büyük ölçekli ortak inşaat ekipleri gitflow'u benimser ve daha büyük ekipler ana geliştirme modelini benimser. Mikro hizmet tasarımının popülaritesi nedeniyle, uygulama ekibinin ölçeği gittikçe küçülüyor, bu nedenle Ali şubesindeki araştırma ve geliştirme modeli daha popüler olacak.
Teknoloji yığını: java, C ++, komut dosyası sınıfları, vb., Kullanıcıların tek bir tıklamayla bir kod çerçevesi ve derleme ortamı oluşturmasına yardımcı olmak için kod önerisi ve şablonlama kullanacağız.
Dağıtım şablonları: Yaygın uygulamalar paket şablonları ve Dockerfiles'tır. Alibaba'da birçok BU mimari lideri ve PE, sıradan geliştiricilerin ortamı hızlı bir şekilde dağıtmasına yardımcı olmak için çeşitli teknoloji yığınlarının temel görüntülerini sağlayacak ve benzer teknoloji yığını yönetimi ve kontrolü de taşınacak araçlara dayanacak.
Son olarak, entegre teslimat gereksinimlerini karşılamak için çok sayıda teslimat süreci türü uygulamak için çok seviyeli boru hatlarına güvenin.
Tek noktadan platform
Şu anda gördüğünüz, mevcut Alibaba Cloud Ar-Ge işbirliği platformunun genel resmidir ve bu iki bölüme ayrılabilir: proje işbirliği ve sürekli teslimat.Teslimat kısmı, talepten geri bildirime kadar tam bir kapalı döngü oluşturur.Geri bildirim kısmı sadece performans ölçümü ile ilgili değildir. Ayrıca, işletmenin kendisi için kamuoyu analizi ve anket anketlerinin yanı sıra akıllı müşteri hizmetleri araçları da vardır.
Mühendis kültürü iniş platformu
Son olarak, mühendis kültürünü platforma yerleştirmek olan platform araçlarımızın nihai amacından bahsedeyim. Elbette mühendis kültürü hayali bir şeydir ve her şirketin kendi kültürü vardır. Alibaba'nın kendi dahili Taobao departmanı dahil olmak üzere B2B, Alibaba Cloud ve diğer BU'lerin kendine has özellikleri vardır. Ancak özetle şu dört nokta olacaktır:
-
Kalite kültürü: Kalite, sürekli teslimatın özüdür ve ekip büyümesinin tek yoludur. Kalitenin kültürel mirası olmadan, verimlilik hakkında konuşmak imkansızdır, kod hızla bozulur, kimse hareket etmeye cesaret edemez ve teknik bir borç haline gelir. Hızlı yineleme ve sürekli teslimattan bahsetmeye bile gerek yok.
-
İnovasyon kültürü: Bir Ar-Ge merkezi olarak, tüm araç inovasyonunun ve verimlilik inovasyonunun kaynağı olmak imkansız ve gereksizdir. Ali'nin de güçlü bir inovasyon kültürü var Bugün bir fikirle çarpışıyoruz ve yarın bir grup arkadaş onu bir araca veya küçük bir ürüne dönüştürecek. İnovasyon keşfedildikten sonra, hızla bir dizi ekolojiye dönüşecektir. Bunlar her gün olur. Takım platformumuz için en iyi yenilikleri platforma koymak, benzer ürünlerin entegrasyonunu teşvik etmek ve tekerlekleri yeniden oluşturmaktan kaçınmak bir taşıyıcı haline gelmelidir.Ayrıca drenajı teşvik edebilir ve daha güçlü ve daha büyük hale gelebilir. Olumlu bir döngü oluşturun.
-
Tam yığın kültürü: Şu anda devop'lardan bahsediyoruz, ancak araçsız devop'lar temelde boş konuşmalar. Platformumuz, işlemlerin otomatik olarak tamamlanması için geliştirmeye yardımcı olabildiğinde veya bilgi öğrenmeyi yönlendirip teşvik ettiğinde, Ar-Ge, test, operasyon ve bakım iş birliğini başarabiliriz Çıkmaz yok.
-
Yalın kültür: Bu, tek noktadan platformumuzun felsefesidir: geliştiricilerin veya liderlerin ürün değerini değerlendirmelerine ve ekip verimliliğini optimize etmelerine yardımcı olmak için değere dayalı teslimat, verilere dayalı doğru ölçüm.
Yukarıdakiler, Alibaba'nın dahili Ar-Ge araçlarının yapımına ilişkin uygulamalarımızdan bazıları ve fikirleri paylaşıp birlikte tartışabilmeyi umuyoruz.
İki büyük zorluk: kalite ve verimlilik
Daha sonra mühendislik alanında ebedi bir konu olabilecek bir konuyu, kaliteyi ve verimliliği tartışacağız, bugün internet senaryosuna, yazılımımızın hem gerekli hem de gerekli sorunları nasıl çözebileceğine odaklanacağız.
Önce İnternet çağındaki zorluklarımızdan bazılarına bakın:
Teslimat hızı pazarı belirlediğinde: CTO'muz bir keresinde Ar-Ge araçlarının bir fikrin doğuşundan lansmanına kadar 2 hafta içinde tamamlanmasını sağlaması gerektiğini söylemişti, denemek ve hata yapmak hızlıdır. Geleneksel araştırma ve geliştirme yöntemleri için bu çok zor görünüyor, ancak gerçekte oldu.
Bu öncül altında, kalitemiz ve verimliliğimiz nasıl seçim yapacak?
Bir uçak kullanmak motorları değiştirecek mi? Önceki varsayımlarımıza dayanarak, önce pazarı işgal etmek ve ardından yinelemeli olarak optimize etmek, temelde yazılım araştırma ve geliştirmemizin fikir birliği haline geldi. Şimdi birisi araba kullanırken uçak değiştirdiğimizi söylerse, sadece "hehe" yapmam gerekebilir, çünkü bunu sık sık yapıyoruz, değil mi?
Sürekli entegrasyon zorluklarla karşı karşıya
Sürekli entegrasyonda karşılaştığımız zorluklara bakalım:
Test kapsamı olmadan sürekli entegrasyon bir yük haline gelir. Tekli testleri ve API testlerini zayıf bir şekilde yaptığımızda, süreç yoluyla empoze edilen sürekli entegrasyon, temelde kararsız veya etkisiz kendi kendini kandırmadır.
Test ekibinin dönüşümü ve tam yığın geliştirmenin neden olduğu kalitenin bozulması. Bu kadar çok ihtiyacım var, test yazmaya zamanım yok ya da dadı hizmetine alışkınım, bu farkındalığa sahip değilim vs.
Test ortamının karşılıklı bağımlılığı istikrarsız faktörler üretir ve Ali'nin entegre ortamı sorunu, geliştirme sürecinde önemli bir sorun noktası olmalıdır.
Bu kadar çok soru gördükten sonra, mükemmel testi teşvik etmekten başka ne yapabiliriz diye düşünmemiz gerekiyor?
Araçlardan verimliliğe
Bugün konuşmak istediğim şey, araçların verimli olması ve hem kalitenin hem de verimliliğin vurgulanması gerektiğidir. Öncelikle nerede verimlilik elde edebileceğimize bakalım.
-
İlk hızlı geribildirim, sanırım verimlilik için aklımıza gelen ilk kelime hızlı, bu da hızlı geri bildirim. İnşaat hızını artırın ve dönüş hızını artırın.
-
İkincisi işbirliğidir, çünkü iletişim maliyetleri programcılar için genellikle büyük bir masraftır ve bu konuda pek iyi değiliz, değil mi, çoğu zaman IQ ve EQ'nun ters orantılı olduğunu görüyoruz. Bu nedenle, işbirliği maliyetlerini azaltmak, şube geliştirme modu, çevrimiçi inceleme, mobil ofis vb. Gibi verimliliği etkili bir şekilde artırabilir.
-
Üçüncüsü yeniliktir: Orijinal kapsamlı tip ve insan gücü tipi devam edemediğinde, inovasyon tek çıkış yolu olabilir. Çift motor testi, alay testi vb.
Yukarıdaki üç noktayı tek tek örneklerle tanıtacağım.
İşbirliği maliyeti
Önce bir işbirliği örneğine, iki araştırma ve geliştirme modelinin karşılaştırılmasına, şube geliştirmeye ve omurga geliştirmeye bakalım.
Sözde dal geliştirme, herkesin gereksinimler, hatalar vb. Gibi dalda kodlama yaptığı ve entegrasyon gerektiğinde paketlenmiş sürüm için geçici bir sürüm dalında birleştirildiği ve sürüm tamamlandıktan sonra ana hat ile birleştirildiği anlamına gelir.
Sözde omurga geliştirme, geliştiricilerin doğrudan omurga üzerinde kodlama yapmaları, geliştirme tamamlandıktan hemen sonra omurgayı göndermeleri ve piyasaya sürüldüğünde paket sürümü için en son omurga kodunu kullanmaları anlamına gelir.
Tamam, iki Ar-Ge modelinin karşılaştırmasına bakalım:
-
Öncelikle şube açıp açmama arasındaki farka bakın. Şube geliştirme modunun her özellik için bir şubesi vardır, bu da yönetime ve kontrole elverişlidir.Dalı gördüğünüzde ne olduğunu hemen anlayacaksınız. Ana hat modu, commit ile ayırt edilen ana hattı doğrudan gönderir.
-
İkinci nokta, Ar-Ge dalının birden fazla entegrasyon ve sürüm gerektirmesidir, bu da kaçınılmaz olarak tekrarlanan çatışmalara neden olur ve entegrasyon sonrası testler test geri bildirimlerinin gecikmesine neden olur. Omurga geliştirme, çatışmayı yalnızca bir kez çözmelidir ve teslim edildikten sonra entegre edilebilir.
-
Üçüncü nokta, bir dal işlevi serbest bırakılmak istemediğinde, dallanma modunun doğrudan entegrasyondan çıkabilmesi ve serbest bırakılması gereken dalın birleştirilip yeniden serbest bırakılabilmesidir. Omurga geliştirme genellikle karşılık gelen işlevleri kapatmak için özellik anahtarlarını kullanır, çünkü kod sıyırma daha zordur.
-
Dördüncüsü, belirli bir çevrimiçi sürüm geri alındığında, ana hattı dallanma modunda geri alabiliriz ve bir sonraki sürüm dalı, hata kodlarının tekrar tekrar çevrimiçi olarak gönderilmesini önlemek için otomatik olarak geri alınacaktır. Omurga modu düzeltme gerektirir ve sonraki sürümler bundan önce engellenebilir.
Yukarıdaki dört sahneyi karşılaştırarak, işbirliğine nispeten elverişli olanları siyah olarak ve beyaza elverişli olmayanları işaretledik. Branş modunun biraz daha iyi göründüğü, özellikle üçüncü noktada fonksiyonel branşlara dayalı keyfi entegrasyonun Ar-Ge öğrencilerine yüksek derecede özgürlük sağladığı görülmektedir. Uygulamada, araç desteği yoluyla, net iş bölümü, daha az bağlantı ve mikro hizmet personelinin hızlı yinelemesi senaryosunda, şube geliştirme entegrasyonu ile ilgili geri bildirimin gecikmesinin eksiklikleri büyük ölçüde azaltıldı.
Hızlı geri bildirim
Şimdi bir sonraki verimlilik noktasına bakalım: hızlı geri bildirim. Geliştirme sürecinde test senaryoları kademeli olarak biriktikçe test süresi de artıyor. Uygulama süresi 30 dakikaya ulaştığında dayanamayacağımı düşünüyorum. Birkaç fincan kahve yedim ve test hala çılgınca devam ediyor. Burada bu hedefe hızlı bir şekilde ulaşmak için daha ilginç bir araç sunmak istiyorum ve biz ona doğru dönüş diyoruz. Birkaç özelliği vardır: Ara yazılım tam bağlantı izleme teknolojisi yardımıyla, test senaryoları ile iş yöntemleri arasındaki ilişkiyi kurar, kod değiştiğinde yürütülmesi gereken kullanım durumlarını önerir, doğru bir şekilde geri döndüğünde ve hızlı geri bildirim sağlar.
Mimari diyagram
Bu resme bir bakın. İlk olarak, izleme, test kodunu ve uygulama kodunu biriktirmek için ara yazılım eklentimiz olan eagleeye'yi kullanıyoruz ve taceid enjekte ediyoruz. Test senaryosu yürütüldüğünde, test senaryosunun tam bağlantı günlüğünü kartal gözü günlüğü olan uygulama koduna kaydederiz ve test kodu ile uygulama yöntemi arasındaki ilişkiyi hesaplamak için günlük toplama yoluyla gerçek zamanlı hesaplama motoruna göndeririz.
Örneğin, bir test senaryosu kapsamında hangi uygulama kodunun kapsandığına hakim olduğumuzda, kod değiştiğinde, doğal olarak onu hangi kullanım durumlarının kapsayabileceğini biliriz, bu kullanım durumları yürütüldüğü sürece, test süresi onlarca dakika kısalır. Birkaç dakikaya veya birkaç saniyeye kadar, verimlilik artışı çok büyük olacaktır.
Elbette, bu çözüm kusurlu veya kusurlu değildir. Entegrasyon aşamasında, eksiksiz bir kullanım senaryoları seti çalıştırmanızı öneririz, ancak bu önemli değildir. Sonuçta, geliştirme aşamasında test etme ve çalıştırma sıklığı entegrasyon aşamasındakinden daha fazladır.
İnovasyonu test edin
Önce üç soruya bakalım: Sınav kapsamı tamamlanmadıysa ne yapmalı? Test senaryoları yazmak, özellikle iyi olanlar, çok zaman alır. Beta testinin neden olduğu varlık kaybı hatası ile nasıl baş edilir? Gerçek trafik girdikten sonra bir hata varsa kesinlikle bazı sorunlara neden olur.Etki küçük olsa da bazı telafisi mümkün olmayan sorunlara da neden olur. Test verilerinin bakımı zordur ve genellikle kontamine olur Bu karmaşık ve baş ağrısıdır.
Tmall iş ekibi, yukarıdaki sorunları çözmek için çift motor testi adı verilen bir platform oluşturdu. Çevrimiçi veri toplama, çevrimdışı hizmet izolasyonu, tekrar yürütme ve karşılaştırma yürütme ve regresyon çalışmasının otomatik olarak tamamlanması yoluyla kapsamı artırmamıza ve verimliliği büyük ölçüde artırmamıza yardımcı olabiliriz. .
Mimari diyagram
Bu mimari şemaya bakabilirsiniz.Solda çevrimiçi hizmettir. İlk olarak, istek ve yanıtın yanı sıra aşağı akış sisteminin çağrı bağlantısı anlık görüntüleri, önbellek, db vb. Dahil olmak üzere çevrimiçi istekler müşteri aracılığıyla toplanır. Mq mesajını oynatmak için beta ortamında istemciye gönderin.
Burada sadece bir oynatma talebinde bulunarak tamamlandı mı? Açıkçası hayır. Aracın özü, uygulamanın tüm aşağı akış bağımlılıklarını izole etmek ve taklit etmektir.Örneğin, uygulama veritabanına bir sql sorgu verisi gönderir. Çift motorlu test platformu bu isteği engeller ve aynı sorgunun anlık görüntüsünü çevrimiçi olarak döndürür. veri. Son olarak, gerçek zamanlı karşılaştırma için uygulama yanıtı elde edilir ve tutarsız sonuçlar saklanır.
Bu mekanizma sayesinde, çevrimiçi istekleri, çevrimdışı oynatma testlerini kolayca uygulayabilir, hata ayıklayabilir, iş kodunun kendisini test etmeye odaklanabilir ve paraziti önlemek için bağımlılıkları izole edebiliriz.
Bu araçla, kullanım durumu yönetimi, arıza analizi, çevrimdışı oynatma vb. Gibi birçok ürünü de büyütebiliriz. Şu anda platform, Alibaba'da kendi ekosistemini, iniş çekirdek uygulamalarını oluşturdu ve çoklu çekirdek kod yeniden İş yükseltiliyor.
Teslimat zorlukları ve DevOps uygulamaları
Daha önce Alibaba'nın sürekli teslimatının bazı geçmiş uygulamalarını ve mevcut kalite ve verimlilik zorluklarını tanıtmıştık.Ardından, şu anda yaptığımız ve araştırdığımız iki yönden, teslimattan ve devoplardan bahsedeceğim.
Özel bulutların uluslararasılaşması ve dönüşümü
Teslimat konusuna gelince, geleneksel şirketler kesinlikle yabancı değildir ve mutlak uzman oldukları söylenebilir. Ali gibi internet şirketleri artık yeni teslimat sorunlarıyla karşı karşıyadır. E-ticaret sistemini ortak girişim şirketine bağlamak istediğimizde ne yapmalıyız, alt yapıyı ihraç etmek ve Alibaba teknoloji sistemini tamamlamak istiyorsak ne yapmalıyız, çok uygulamamız olduğunda ve ağ bağımlılığı oluşturduğumuzda ne yapmalıyız? Kulağa çok büyük bir şey gibi geliyor, değil mi?
Şu anda, iki teslimat değişikliğimiz birleşik teslimattan toplu teslimata değişti.Örneğin, önce e-ticareti orta aşamada, ardından e-ticaret üst düzey iş uygulamalarını ihraç ediyoruz. Genel teslimattan kısmi teslimata kadar, tüm çıktı tamamlandığında sürüm yinelemeleri gereklidir. Bu kadar büyük bir uygulama ölçeği genel teslimat için kullanılamaz. Şu anda, kısmi teslimat gereklidir. Ve bu blok her seferinde farklı olabilir. Bu şüphesiz aletlere yeni zorluklar getiriyor.
Teslimat verimliliği sorunu
Verimlilik hakkında konuşalım, burada üç noktayı sıraladım:
Hızlı bir şekilde oluşturun: Düşük maliyetli, tek tıklamayla oluşturma ortamına ihtiyacımız var, sorunları yeniden üretiyor veya teslimat sürümü için entegre bir test ortamı oluşturuyoruz.
Regresyon testi: Ortamda hizmetlerin birden fazla sürümü olduğunda nasıl yapılır ve yeterince hızlı nasıl yapılır
Bağlantı yönetimi: Teslimat süreci tek tıkla yapılabilir mi ve teslim edilen sürüm, teslimat risklerinden kaçınmak için görünür ve kontrol edilebilir mi?
Aşağıda yukarıdaki üç noktaya örnekler veriyoruz.
Teslimat süreci keşfi
Burada teslimat sürecini tanımlama, karşılaştırma regresyonu, hızlı derleme, doğru regresyon, tek tıklamayla teslimata dayanarak bu boru hattına yazdım.
Önce bağımlılık tanımlamasına bakın.Neden bağımlılığı tanımlamamız gerekiyor? Daha önce de bahsettiğim gibi, uygulamalarımın sayısı çok fazla ve ağ bağımlılıkları çok karmaşık olduğunda, insanların bağımlılıkları tanımlaması artık güvenilir değil. Ve bir işlev sunmak istiyorum Eğer tüm vücudu harekete geçirirsem ve ilgili tüm uygulamaların genel çıktıya ulaşmasına izin verirsem, dahil olan çok sayıda ekip temelde sürdürülemez. Bu nedenle, otomatik bağımlılık tanımlamasını tamamlamak için araçlar kullanılmalıdır. Bu, tam bağlantı arama verilerinin yardımıyla yapılabilir.
Örneğin, A1 sürümünü değiştirdim ve bağlantı verilerini teslim sonu bağlantı anlık görüntüsü ile birleştirdim ve iki sürüm B1 ve C1'in yol boyunca teslim edilmesi gerektiğini buldum. Şu anda, sistem bir teslimat setini tanımlamama yardımcı oldu ve sonraki testler buna dayalı olabilir. Açın.
Entegrasyon testi başlamadan önce, yeni tanıtılan çift motorlu test platformunu veri oynatımı gerçekleştirmek, testleri karşılaştırmak ve teslim son verileri üzerindeki etkisini onaylamak için kullanabiliriz.
Entegrasyon Testi
Daha sonra, entegrasyon testi aşamasına gireceğiz.İlk olarak, hızlı bir şekilde inşa edeceğiz.Uygulama konteyneri düzenlemesi ve ara yazılım izolasyonuna dayalı olarak, A1, B1 ve C1'i küçük bir entegrasyon bağlantısı oluşturmak için kolayca izole edebiliriz. Hassas regresyon teknolojisi sayesinde değişen işlevler hakkında hızlı geri bildirim.
Tek tıkla teslimat
Sonuncusu tek tıkla teslimat Temel sürüm yönetimi yeteneklerine ek olarak, Ar-Ge personeli için teslimat sürecinin maliyetini en aza indirmek için grup ortamında teslimat ortamını da doğrudan yönetebilirim. Aynı zamanda, teslimat tarafında, teslimat risklerini daha da azaltmak için gri sürüm özelliklerini destekler.
En önemli şey sorunsuz bir geri bildirim kanalına sahip olmaktır.Yukarıda tanıtılan platform ürününün büyük resmine, kamuoyu ve Soru-Cevap gibi geri bildirim modülünün zengin işlevlerine güvenerek, teslimatın sonunu hızlıca kavrayabilir ve gerekli önlemleri alabilirim.
Pekala, yukarıdakiler, mevcut yeni teslimat sorunlarına yaklaşımlarımızdan bazıları. Benimle derinlemesine tartışmaya hoş geldiniz.
DevOps'un anahtarı araçlardır
Son konu olan devops, burada ayrıntılara girmeyeceğim, sadece deneyimlerimizin bir kısmından ve geçen yıl devopların dönüşümündeki küçük bir yenilikten bahsedeceğim.
Alibaba Group, 15 yıllık dönüşümden bu yana, kurumsal PE ekibinin çoğunu kaldırdı ve geliştirmeye devretti. 2016'da, birleşik bir zamanlama platformu oluşturduk ve docker konteyner teknolojisini uyguladık ve temel uygulama yükseltmesini tamamladık. 2017, Ali'deki yenilikçiler için en görkemli yıl olabilir. Bu yıl, tüm aktif uygulamaların konteynırlaştırılmasını ve eksiksiz bir yukarı ve aşağı takım zincirinin inşasını tamamlayacağız.
Burada üç noktayı listeledim: Birincisi, Ar-Ge, uygulama yapılandırması, ortam, yazılım temeli, çevrimiçi değişiklikler ve boru hattı kontrolü için en temel işlemler nelerdir. Bu her gün kullanılıyor.
Konteynırlaştırmadan önce böylesine karmaşık bir sette iyi bir iş çıkarmadık Konteynırlaştırmaya başladığında, ortamımız daha da standart hale getirildi, kod temelli değişiklikler gerçekleştirildi ve yönetim araçları büyük ölçüde basitleştirildi. Önceki temel araçlara, yazılım paketi doğrulama araçlarına ve toplu yürütme araçlarına artık gerek yoktur. Destekleyici planlama sistemi aracılığıyla, çevresel kaynaklar gerçekten Ar-Ge öğrencilerine devredilir.
İşletme ve bakım sistemi basitleştirilmeye başlandı, servis batmaya başladı, self servis operasyon kendi kendini iyileştiren bir türe dönüştürüldü ve akıllı çözümler başlatıldı. Örneğin, esnek zamanlamayı teşvik etmek için.
Ali'de DevOps
Güzel görünüyor, değil mi? Ops'un geliştiriciler için, özellikle ilgili işlemler ve bakımla ilgili temel bilgi eksikliği ve problem çözme yeteneklerinin eksikliği gibi önemli zorluklar yarattığı inkar edilemez. Sadece Ops'u DevOps'a DevOps vermek mi? Tabii ki hayır, bu sadece kalkınmaya bir zarar değil, aynı zamanda verimsiz bir uygulamadır. 1000 kişinin şimdiye kadar yapabilecekleri 10.000 kişinin tamamlanmasını gerektirir.
Yani DevOps'a yük yapamayız, DevOps robotları yolda.
DevOps robotu
Devops robotları, aslında geliştiricilerin herhangi bir zamanda bilgi eklemelerine ve sorunları çözmelerine yardımcı olan veri tabanlı aktif hizmet robotlarıdır ve kendi kendine kapalı bir bilgi edinme döngüsü sağlamak için bir mekanizmamız var.
Veriler ilk olarak nereden geliyor? Yaygın, derleme hataları, makinedeki hata günlükleri, dağıtımla ilgili, kapsayıcıyla ilgili vb. Önce bunları topluyoruz, ardından kod değişikliği Diff, konfigürasyon değişikliği gibi kullanıcının davranışları ile işbirliği yapıyor ve veri platformuna kaydediyoruz.
Verilere sahip olduğumuzda, kurallar oluşturmak için uzmanlardan gelen bilgi tabanları, araç işlemleri ve sıradan geliştiriciler gibi insanların birikimiyle olan ilişkiyi analiz etmek için makine öğrenimini kullanırız.
Aynı sorun tekrar ortaya çıktığında, sistem geliştiricilerin sorunu çözmesine yardımcı olmak için otomatik olarak ilgili çözümler önerecek ve modeli eğitmek için geri bildirim toplayacaktır.
Veri birikimimiz ve Problem Meydanı gibi ürünlerin inşası sayesinde, kapalı bir problem ortaya çıkma döngüsü = "çözüm itme =" kullanıcı geri bildirimi = "bilgi katkısı. Şu anda, basit birikimimizle% 70'in üzerinde bir eşleştirme oranına ulaştık.Gelecekte kapalı döngü bilgi eğitimi ile devops robotlarının daha akıllı olacağına inanıyoruz.
yazar hakkında
Chen Xin (Shenxiu), Alibaba Cloud'un sürekli teslimat platformunun ve Ar-Ge araçlarının yapımından sorumludur. Kendini kurumsal Ar-Ge verimliliği, ürün kalitesi ve DevOps yönünün araştırılması ve araştırılmasına adamıştır. Ali'de 6 yıl boyunca büyük veri test ekibine, test aracı geliştirme ekibine ve sürekli teslim platformu ekibine liderlik etti. Ar-Ge işbirliği, test, teslimat, işletim ve bakım konularında derin içgörülere sahiptir.
Bugünün TavsiyesiOkumak için aşağıdaki resme tıklayın
En yeni yüksek tanımlı BT kariyer beceri haritasının ücretsiz indirilmesi: makine öğrenimi, mimar, büyük veri
2017 Küresel Mimar Zirvesi sürüyor! Dr. Ali Wang Jian, Tsinghua Üniversitesi'nden Profesör Deng Zhidong, Hulu Global Başkan Yardımcısı Zhuge Yue ve diğer teknik uzmanlar GeekTime Uygulamasını paylaşıyor!
Geek Time Uygulamasını hızlıca açın, meslektaşlarınız ve arkadaşlarınızla paylaşın ve canlı yayını birlikte izleyin!
