Aşırı endişe duymadan üretim dağıtımlarını nasıl otomatikleştirebilirim?

Mağazamızda, geliştirme, test ve entegrasyon ortamlarımıza otomatik kurulumlar ve dağıtımlar yapmak için kaynak kontrolü için SVN ve CI için CruiseControl kullanıyoruz.

Tüm bunlar sorunsuz çalışır, ancak donanım ve kaynak kısıtlamaları nedeniyle, entegrasyon ortamımız üretim ortamımız gibi 2 sunucu yükü dengeli bir ortam değildir. Her şey eşit olsa da, bu bizim entegrasyon ve üretim ortamları arasındaki tek fark olacaktır (büyük bir tane olsa bile!)

Teorik olarak fark, uygulama sunucularımızın biraz farklı bir konfigürasyonudur ve konuşlandırma komut dosyası yalnızca yapı nesnelerini yalnızca bir sunucu yerine iki sunucuya bırakmak zorunda kalacak, ancak neden üretim dağıtımlarımızı otomatikleştirmek için bu kadar gerginim ?!

Genelde bir kontrol manyağı değilim, ancak üretimi el ile üretime geçirme konusundaki doyumsuzluğa her zaman ihtiyaç duyuyorum. Meslektaşlarımdan bunun genel olarak Gerçekten Kötü Bir Şey Şey olduğunu duydum ama buna karşı dava açamadılar.

Manuel olarak yaptığımda, doğru dosyaları fiziksel olarak kopyaladığımı görebildiğimi görebildiğimi, uygulama sunucularını fiziksel olarak kapattığımı ve başarılı bir şekilde kapandıklarını sağladığımı, sunucuları fiziksel olarak yeniden başlatacağımı ve ardından günlükleri yapmak için fiziksel olarak denetlediğimi biliyorum Tamam başladığından ve dağıtımın başarılı olduğundan emin olun. Bana huzur veriyor.

Otomatik kodlanmış üretim dağıtımı için bu VEYA argümanlarına karşı argümanlar nelerdir?

Buna karşı açık bir kaç argüman var.

1. Ayrılırsan ne olur? Tüm bu bilgiler dikkatlice belgeleniyor mu, yoksa çoğunlukla kafanızda mı? Otomatik komut dosyaları, başkasının devralması için çok daha iyi bir yerdir.

2. Herkes hata yapar. Konuşlandırmayı yapan kişinin yorgun olduğu, ne olursa olsun dikkat etmediği bir zaman gelecek. Evet, ideal olarak konuşlandırmalar sadece çok sakin ve mutlu bir yerde yapılır. Uygulamada, acil düzeltmeleri çıkarmaya çalışırken aceleye getirilebilir ve vurgulanabilirler. Bu bir hata yapmak için en muhtemel zamandır ve aynı zamanda en masraflı olanıdır. Dağıtım tek bir komut dosyasıysa, hata olasılığı sınırlıdır.

3. Zaman. Dağıtımlar daha da karmaşıklaştıkça, yapılması gereken miktar artar. Scriptler sadece başlama, manuel kontrol ve daha sonra manuel geçiş gerektirir (bunu da otomatikleştirebilirsiniz, ancak paranoyayı da paylaşıyorum :).

En iyi dünyanın en iyisini elde edebilirsiniz: süreç doğrulaması ve otomasyonun güvenilirliği ile iç huzurunuz.

Dağıtım komut dosyası. Ardından, işlemlerin başladığını, dosyaların kaldırıldığını vb. İşlemleri doğrulayın ve manuel olarak doğrulayın. Başka bir deyişle, yalnızca otomatik adım 1 - X'in gerçekleştiğini doğrulamak için kendi QA komut dosyanızı yazın.

Burada anahtarın şu olduğunu düşünüyorum: neden doğrulama işlemini kodlayamadığınızı düşünüyorsunuz?

Dağıtım komut dosyalarım yalnızca arşivleri zorlamaz ve hizmetleri yeniden başlatmaz. Dağıtımın her adımı sırasında çok sayıda renk kodlu bilgi yazdırırlar ve sonunda olayların bir özetini sağlarlar. İşlemlerin çalıştığını, ana sayfanın 200 durum kodunu sunduğunu ve tüm makinelerin ve hizmetlerin birbirini iyi görebileceğini bilmeme izin veriyor. Daha sonra günlük dosyalarını, 4xx ve 5xx düzeyindeki hataları ve anahtar site ölçümlerini izleyen komut dosyasının parçası olmayan ayrı bir hizmetim var. Daha sonra, şiddetli olumsuz etki artışı varsa, mümkün olan her araçta (e-posta, txt msg ve alarmlar) bana bağırmaya devam eder.

Bu ve testler çalışan CI sunucuları arasında, tam anlamıyla bu otomasyon seviyesini konuşlandırıp dağıtıyorum. Şimdiki işlemin ne kadar güvenilir olduğundan, yalnızca istediğim sıklıkta dağıtım yapmama izin vermiyor, aynı zamanda projedeki yeni bir geliştiricinin canlı yayın için bir güncelleme yapmasına izin veriyor. Gemiye geldikten birkaç dakika sonra Geçmişte, CI sunucularını, her şeyi geçen bir ana / ana hat şubesine vermiş olduktan sonra otomatik olarak prodüksiyona yönlendirdim. Araçlarımda kendime bu kadar güveniyorum.

Sen de olmalısın.

Ayrıca üretim makinalarınızı uzaktan hata ayıklama ile çalıştırıyor musunuz ve manuel olarak adım atıyor musunuz? Uygun bir komut dosyası oluşturmak, program yazmakla aynıdır. Sahip olduğunuz tüm konular, izlemesi ve kontrol etmesi gereken şeyleri gösterir.

Bir şey yanlış giderse, uygun geri alma prosedürlerinden geçmeli ve size bir mesaj göndermelidir. Olan her şey daha sonra günlüğe kaydedilebilir. Komut dosyalarını kontrol edebilir ve test senaryoları oluşturabilirsiniz.

Ancak el ile komutları kullanıyorsanız, bu avantajlardan hiçbirine sahip değilsiniz. Bunun yerine bir dezavantaj listesi var.

• İyi bir günlüğünüz yok, kabuk geçmişi sayılmaz
• Başka kimse nasıl yapılacağını bilmiyor
• Adımlar kaçırıldı
• Kontroller sadece bazen yapılır
• Dağıtılacak bazı öğeler kaçırılabilir, bunu daha önce yaptım
• Daha uzun sürer
• İşlem sırasında kesintiye uğrayabilirsiniz

Kabukta her şeyi yazdıysanız, uygun bir komut dosyası neredeyse aynı olmalıdır. Bash betiğimizin olmasının sebeplerinden biri de bu. Yaptığınız şeylere güveniyorsanız, neden her şeyi kaydedemiyor ve sıkılamıyorsunuz? Daha iyi kontrol, daha hızlı kontrol, bilgisayar yaptığı için daha fazla kontrol olabilir.

Prod ortamında yeni bir şeyler denemekten biraz gergin olduğumu anlayabiliyorum. Potansiyel felakete karşı temkinli olmak Good Thing ^TM'dir .

Otomatik kodlama da Good Thing ^TM'dir ve dikkatle yaklaştığınız sürece, tehlikeyi en aza indirmeli ve korkunuzu azaltmalısınız. Yani benim tavsiyem bu;

• Bir kontrol listesi / test seti hazırlayın (ve uygulamada uygulayın), böylece işe yarayıp yaramadığını ya da yanlış bir şey olup olmadığını kolayca anlayabilirsiniz. Ayrıntılı günlük kaydı bu konuda yardımcı olabilir.
• Her şeyi yedekle. Kötü bir şekilde ters giderse iyileşmesi için manuel bir geri alma hazırlayın ve uygulayın.
• Prod için gerçekten yapmadan önce mümkün olduğu kadar test edin. Sizin entegrasyon env ile birlikte bu konuda iyi bir yol gibi görünüyor.
• İlk defa denediğinizde, düşük profilli, düşük darbe değişimiyle yapın. Küçük bir yükseltme veya düzeltme eki gibi bir şey. Fikir yanlış giderse serpinti en aza indirmektir. İlk koşunuz için yüksek profilli bir ana yükseltme (CEO ve tüm rakiplerinizin izlediği yer) seçmeyin.

Kemerinizin altında birkaç başarılı koşu yaptıktan sonra, güveniniz artacaktır ve yakında manuel dağıtım yapmayı nasıl başardığınızı merak edeceksiniz.

Manüel olarak üretime dağıtmaya karşı en büyük argüman: İşte sen bir insansın ve hatalar yapacaksın. Hiç şüphesiz, sizi üzecek bir şey yapmayı unutacağınız zamanlar olacaktır. İyi yazılmış bir otomatik dağıtım aynı eğilime sahip değildir. Hâlâ karışık üretim dağıtımlarına sahip olabileceğiniz doğru, ancak bunun nedeni otomatik dağıtımınızın çözülmesi gereken hatalara sahip olmasıdır.

Tecrübelerime göre otomatik dağıtımların üretime sağladığı faydalar çok büyük. Bunlardan en büyüğü, işbirliği yapmayan bir manuel dağıtım sürecinden geçmeye çalışmak yerine, hafta sonları eğlenmek.

Bununla birlikte, üretim dağıtımlarınızı otomatikleştirmek için bazı önemli işaretçiler şunlardır:

• Hepsini bir kerede yapma! Otomatik dağıtımlarınızı yavaşça yazmaya başlayın. Önce ayrı bir üretim dışı ortam oluşturun ve buradaki dağıtımları otomatikleştirmeyi deneyin. Otomatik dağıtımlarınıza güven kazandırdıktan sonra, üretim dağıtımları yapmayı düşünmeye başlayabilirsiniz.
• Çok sık serbest bırakmaya ve dağıtmaya başlayın! Yayınlanmayı bekleyen 4 aylık kodunuz olmadığı zaman otomatik dağıtım yapmak çok daha kolaydır. Küçük özellikler ve hata düzeltmeleri haftada birden çok kez yayınlansın. Bu sürüm stilinin faydaları anlaşılamıyor!
• Üretim ortamınızın işe yarayacağına dair size güven vermek için otomatik testlere güvenin. Yine, bu birikmesi zaman alır, ancak çok önemlidir. Otomatik testler her zaman manuel kabul testlerinden daha iyidir. Elbette, manuel kabul testleri iyi, ancak otomatik testler üretime dağıtıp dağıtmamanız gerektiğini bilmenize yardımcı olabilir. Bu otomatik, sürekli teslimat sürecini sağlayan anahtardır. Testleriniz geçemezse, üretime geçmemeyi bilirsiniz.

Komut dosyalarını canlı sunucuda çalıştırın. İşe yarayacak ve birkaç kez iyi çalıştığını gördükten sonra, tamamen kendinize güveneceksiniz.

Cidden, dağıtım senaryosundan daha fazla hata yapma ihtimaliniz daha yüksek.

Bilgisayarlar hata yapmaz, insanlar yapar.

Komut dosyanızı bir kez yazın ve iyice kontrol edin, satır satır ilerleyin. O andan itibaren, her dağıtışınızda çalışacağından emin olabilirsiniz.

El ile yapın ve hata yapmak zorundasınız. Belki de yazdın, yapmanız gereken her şey, aşağı ama bir hata yapmak çok kolay. Web.config dosyası dışındaki tüm dosyaları kopyalamanız mı gerekiyor? Bir gün bunun üzerine yazacağına bahse girebilirsin. Bir script asla bu hatayı yapmaz.

Aşırı endişe duymadan üretim dağıtımlarını nasıl otomatikleştirebilirim?

Üretim dağıtımlarını otomatikleştirirken karşılaşacağınız aşırı endişe, muhtemelen iki inanca dayanmaktadır:

1. Bir gün veya bir gün, bazı dağıtım adımları başarısız olur ve siz veya başka bir insan otomatik bir komut dosyası görmezden gelirken başarısızlıktan hızla kurtulabilir.

2. Üretimdeki göz ardı edilen bir başarısızlığın çarpıcı sonuçları vardır.

2 hakkında yapabilecekleri çok az şey var, başarısızlıklardan kaçınmanın yanı sıra 1'e odaklanalım.

Tedarikçinin hafifçe iyileştirdiği ucuz bir çözüm, kurulumun her adımının sonunda doğrulama bekleyen yarı otomatik bir dağıtım prosedürü kullanmak olacaktır. Yarı otomatik bir çözümle, tutarlılık ve yeniden üretilebilirlik gibi tam otomatik bir çözümün avantajlarından yararlanırken, şu anda alıştığınız ilerlemeleri izleme ve hataları gidermeye devam etme şansına sahip olacaksınız.

Yarı otomatik senaryo ve biyotopu (regresyon testleri vb.), Kurulum prosedüründe meydana gelen arızalar ve onlardan kurtulmanın yolları hakkında topladığınız bilgiler için bir araç olarak da kullanılabilir.

Sevdiğim şey, konuşlandırmayı aşamalandırma veya KG üzerinde test edebilmeniz ve prod üzerinde çalıştırdığınızda aynı adımların gerçekleşeceğini bilmeniz.

Manuel olarak yaptığınızda bir adımı unutmak veya sıra dışı yapmak daha kolaydır.

... donanım ve kaynak kısıtlamaları nedeniyle, entegrasyon ortamımız üretim ortamımız gibi 2 sunucu yükü dengeli bir ortam değildir. Her şey eşit olsa da, bu bizim entegrasyon ve üretim ortamları arasındaki tek fark olacaktır (büyük bir tane olsa bile!)

Yukarıda verilen, muhtemelen senin kadar endişeli olurdum.

Bir keresinde SLB'ye dağıtan otomatik komut dosyasını inceledim ve test ettim ve yükü dengelenmiş kurulumda ön test yapmadan işleri manuel olarak yapmayı tercih ediyorum.

Prod benzeri test kurulumunun yanı sıra, benim rahatlığım üzerinde önemli bir etkiye sahip olan bir diğer şey de, prod konuşlandırmasının, diğer işi geliştiren ekipler tarafından yapıldı - tek işi üretim ortamını korumak olan adamlar tarafından.

• Projelerin birinde, dev ekip temsilcisi olarak konuşlandırmalarına yardımcı oldum. Dağıtımdan önce talimatlarımı gözden geçiriyorlardı ve dağıtım sırasında işler yanlış giderse danışmaya hazırdım. O zaman, bu ayrılığı takdir etmeyi öğrendim .
   
  Daha hızlı olduklarından değil (neden onlar? 5x-10x dağıtımlarını onlardan daha sık test ettim). En büyük fark odaktaydı. Demek istediğim, kafam daima “ana” şeyler tarafından yüklenir - kodlama, hata ayıklama, yeni özellikler - konuşlandırmaya odaklanmak için çok fazla dikkat dağıtıcı şeyler vardır. O aksine, onların ana malzeme sadece üretim bakım ve onlar o odaklanmıştı.
   
  Odaklandığında beynin ne kadar iyi çalıştığını görmek şaşırtıcı. Bu adamlar, çok daha dikkatli davrandılar, benden çok daha az hata yaptılar. Bu şeyleri benden daha iyi biliyorlardı. Bana kendi test uygulamalarını kolaylaştıran bir iki şey bile öğrettiler.

Kodunuzu herhangi bir ortama taşımak için kullandığınız bir dağıtım komut dosyası oluşturun. Kodu aynı dev, qa, evreleme ve son olarak üretime taşımak için aynı dağıtım işlemini kullanıyoruz. Günde birkaç kez dev'e ve her gün KG'ya dağıtdığımız için, dağıtım komut dosyalarının doğru olduğuna güvendik. Temel olarak, cehennemi sık sık kullanarak test edin.

1. Basitleştirin. Değişiklik işleminiz rsync dosyalarında, SQL komut dosyasını çalıştırın, başka bir şey olmamalıdır.
2. Otomatikleştirmek.
3. Ölçek.

Otomatikleştirmenin nedeni, test edilebilir, tekrarlanabilir ve beklenen her durumda doğru şekilde çalışmak için güvenebileceğiniz bir şey elde etmektir.

Herhangi bir bağlamdaki herhangi bir değişiklik için olduğu gibi hala bir geri plana ihtiyacınız var ve bunun da otomatikleştirilmesi gerekiyor.

Süreci, çevre gerçekten hassassa, olduğu gibi gözlemlemek isteyeceksiniz, ancak hiçbir zaman el ile tam olarak çoğaltılamadığı için yapmayın.

Üretim ortamlarına dağıtmak için otomasyon komut dosyalarını kullanmak tamamen mümkündür. Bununla birlikte, bunu güvenle yapmak için birkaç şeyi yapabilmeniz gerekir.

1. Önceki sürüme güvenilir şekilde geri dönün.
2. Dağıtımın başarıyla uygulandığını ve geçerli trafiğe yanıt verdiğini onaylayın.
3. Aynı komut dosyalarını kullanan geliştirme ve kalite güvencesi için karşılaştırılabilir ortamlara sahip.

Komutların, bir komutu asla kaçırmayacakları, çünkü sabahın 2'si ve yorgun olduğu gibi bazı avantajları var.

Ancak, komut dosyaları hala başarısız olabilir ve olacaktır. Bazen başarısızlık betiğin tasarımında olabilir, ancak bir ağ veya elektrik kesintisi, bozuk dosya sistemi, yetersiz bellek de olabilir.

Bu nedenle, komut dosyası çalıştırıldıktan sonra, tanımlanmış bir test aşamasının da izlenmesi ve canlı trafiğin etkinleştirilmesinden önce yeni dağıtımın yapıldığını, isteklerin çalıştırıldığını ve işlendiğini doğrular.

1. Eğer işler ters giderse, ilk defa konuşlandırmak için daha büyük bir pencereye gidin.

2. Dağıtım işlemini iki bölüme ayırın. a. Yedekleme (manuel) - konuşlandırma sırasında bir sorun çıkarsa bu size güven vermelidir

   b. Dağıtım (otomatik)

bir kez ilk defa güvenle konuşlandırabilirsin. Yedekleme işlemini de otomatikleştirebilirsiniz.