Canlı bir web sitesinin dağıtım hatalarının sayısını azaltmak için ne yapabilirsiniz?

Eminim ki çoğunuz bu sorunu yaşadı. Bir web sitesi veya web uygulaması çalışıyor ve yayında. Bir sonraki sürümü yüklemek istiyorsunuz, ancak yapılandırma dosyasında false olarak bir değer ayarlamak, veritabanına başka bir kayıt eklemek ve bazen 20 veya daha fazla parametreye kadar sayabilen çok sayıda küçük şey yapmak gibi her şeyi çözmediniz.

Yeni sürümü yükler yüklemez her şey kırılır. Şimdi, sorunu çözmek sadece 20 dakika kadar sürebilir, ancak tolere ettiğiniz genel stres ve şirkete mali ve iyi niyet hasarı bazen unutulamaz.

Yeni sürüm dağıtımının ilk yapılandırmasından kaynaklanan bu tür hataları azaltmanın yolları nelerdir?

Not: Lütfen kontrol listelerinden bahsetmeyin, çünkü zaten onlara sahibiz. Kontrol listelerindeki sorun, her zaman güncellenmeleri gerektiğidir, ancak olmayacaklardır.

İki şey:

• Test dağıtımlarını yaptığınız canlı ortama benzer şekilde hazırlama ortamı.
• Konuşlandırmadan sonra bu ortamın kapsamlı testi. Otomatik ve otomatik olmayan.

Yapılabilecek başka şeyler var.

Troy Hunt tarafından otomatik konuşlandırmayla ilgili 5 bölümlük blog dizisini okumanızı öneririm . Kullandığı takım MS yığınına özgüdür, ancak kavramlar evrenseldir.

Acaba, neden hiç kimse Sürüm kontrolünden bahsetmedi - bu güncelleme / yükseltme sırasında sizi sıkıntıdan kurtarmanın en önemli yollarından biri .

İlk olarak, dağıtımınız deponuzdaki sabit dalın sadece bir kopyası olmalıdır. Yapılandırma dosyaları, SQL dosyaları, yükleme / güncelleme komut dosyaları dahil her şey sürüm kontrollü olmalıdır.

İkincisi, "bir çeşit" hazırlama alanına sahip olmanız gerekir - herhangi bir şey olabilir - yerel bir sunucu, yeni doğduğunuz geçici bir sanal bulut sunucusu, çok basit bir sanal ana bilgisayar kurulumu veya tam teşekküllü bir özel uygulama ana uygulama ile birlikte korumak. Bu "aşamalandırma alanı" ile "geliştirme alanınız" arasındaki fark, eskisinin gerçek dağıtım ortamınızı daha yakından modellemesi (veya benzetmesi). Örneğin, Apache modülü ile PHP 5.3.x üzerinde geliştirebilirsiniz, ancak sunucunuz FCGI ile PHP 5.2.x olduğundan, hazırlama alanı aynı olmalıdır.

Ardından, güncellemelerinizi geliştirme ortamınıza yazar ve test edersiniz. Bu değişiklikleri hazırlama alanı deposunda birleştirin ve tekrar test edin. Bu noktada, yapılandırmanıza dağıtımınıza uyacak şekilde herhangi bir değişiklik yapabilirsiniz - sürüm kontrollü olduğundan hiçbir şey kaybolmaz ve sorun olduğunda her zaman geri dönebilirsiniz.

Son olarak, canlı dağıtım kopyanızdaki hazırlama alanı değişikliklerini birleştirin.

Evreleme alanınızın karmaşıklığı, uygulamanızın karmaşıklığını ve kapsamını yansıtmalıdır. Ancak her durumda Sürüm kontrolü vazgeçilmezdir.

Tabii ki Sürüm kontrolü kullanmazsanız - bunların hiçbiri geçerli değildir - ancak Logo'da bir veritabanı yazmak kadar naiftir.

Önerildiği gibi, bir evreleme sistemi kullanın . Bu, değişikliklerinizi canlı bir ortamda test etme fırsatı verir.

Bu başka bir noktaya daha geliyor: test kullanıcıları var . Kendim yazdığım şeyleri test etmek, başka birinin başvurumu test ettiğinde olduğu kadar hata bulamıyor.

Başka bir şey: dağıtım işleminizi otomatikleştirin . Karınca göçü ile db geçişleri yapın, en yeni sürümü svn'den capistrano vb. Aracılığıyla otomatik olarak dağıtın. Bir şey dağıttığınızda, sadece bir tıklamadan daha fazlasını yapmak zorunda kalmamalısınız ve her şey otomatiktir. Özellikle bazı yapılandırma kurulumlarına ihtiyaç duyan web siteleri için, dağıtım için gereken manuel adımlar bir kabus ve bir şeyin yanlış gitme olasılığı çok yüksektir.

Kesinlikle, olumlu bir şekilde kırılmaması gereken bir şey için, A ve B sistemine sahip olmayı düşünün ve B'yi yükseltirken ve test ederken tüm istekleri A'ya yönlendirmek için bir yük dengeleyici kullanın ve ardından A'yı güncellerken her şeyi B'ye yönlendirin.

Bonus puanlar için C ekleyin ve sistemlerin coğrafi olarak ayrıldığından emin olun, böylece bir deprem aynı anda 2 tanesini dışarı çıkarmaz.

Birçok uygulama için, bunun aşırı kilolu olduğunu kabul ediyorum.

Ayrıca, yapmanız gereken herhangi bir işlem yönetimini karmaşıklaştırır, ancak sorunlar aşılmaz değildir.

Evet, tüm adımları uyguladığınız bir test veya hazırlama ortamına ihtiyacınız vardır, ancak ayrı ortamlar için ayrı yapılandırma dosyaları tutmak bir zorunluluktur.

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

Temel olarak derleme ve dağıtım betiklerimde, XML dosyaları gibi ortama özgü meta veri dosyalarını getirecek ve paketlemeden önce bunları derleme konumumda değiştirecek bir ortam özelliği alıyorum. Dahası dağıtım betiklerimde veritabanı güncellemelerinde herhangi bir SQL dosyası arayacağım ve bu ortam için yapılandırılmış veritabanında da yürüteceğim.

Bunu özel bir inşa göreviyle yapabilirdim, ama aslında bunu yapmak için bazı JUnit testlerini kullanıyorum . SQL istisnaları oluşursa, sınama başarısız olur ve dağıtım başarısız olur. Genel olarak SQL komut dosyalarının da istihbaratları vardır, eğer gerekli veriler ortamda zaten mevcutsa, ekleme veya güncellemeyi atlarlar.

Ayrıca belirli bir ortam için çalıştırmanız gereken toplu iş veya kabuk komut dosyaları için benzer bir dizin var.

Sorunuzdaki her şey şu: her zaman güncellenmeli, ancak olmayacaklar.

Bu yapılandırmalar otomatik derlemelerinizi ve dağıtımlarınızı yönlendirir, böylece bunları güncellemezseniz derlemeleriniz başarısız olur ve yöneticiniz bu konuda e-postayla gönderilir. Ekibin belirli bir sürüm için derleme ve dağıtım yapılandırmalarını sürdürmesi, derleyen kodu teslim etmeleri kadar önemlidir. Her iki ihlal de yapıyı bozar.

Kısacası, sürekli entegrasyon (CI) ilkelerinin daha fazla benimsenmesi , üretim sürümlerinin ağrısının giderilmesine yardımcı olacaktır.

1) Önce test sitesine konuşlandırın ve değişikliklerinizi test edin

2) Tüm yapılandırmayı bir yapılandırma dosyasında (web yapılandırması veya benzeri) bulundurun. Bu yapılandırma daha sonra uygulamaya özgü olmalı ve hiçbir zaman üzerine yazılmamalıdır. Daha sonra herhangi bir değişiklik, testten farklı olması gereken bir şeyi değiştirmeyi unutmak yerine kasıtlıdır.

Üretim öncesi bir ortama sahip olmak ve otomatik test kullanmak için yukarıdaki mükemmel önerilere ek olarak:

Kod tabanının karmaşıklığını azaltın . Daha az kod, genellikle, daha az hata ve bunları bulmak için daha kolay bir zaman anlamına gelir. Bu, yeniden düzenleme, kaygıların ayrılması ve benzeri şeylerin arkasındaki felsefedir.

Kod tabanını bölümlere ayırın . Ortak bir yaklaşım, onu ayırmaktır:

• yavaş değişen ve site genelinde paylaşılan birkaç temel bölüm
• daha hızlı değişebilen ancak her biri sitenin yalnızca küçük bir bölümünü etkileyen birçok yaprak parçası

Kod tabanınızın bu anlayışı, geliştirme ve testinizi temel parçalara odaklamanıza izin verir, çünkü hatalar en sert etkiye sahip olacaktır.

İyi yürütülen bir sürüm tamamen planlama ve iletişim ile ilgilidir. Dolayısıyla, bir yayın yapmadan önce şu soruları göz önünde bulundurun:

1. Sürümün ne kadar süreceği ve sürüm devam ederken insanların ürünümle arayüz kurmaya devam etmelerine izin verme riski var mı? Sistem için bir risk varsa, sistemi çevrimdışına almayı ve yerine "Şu anda bakımda olan sistem" mesajını koymayı düşünün.

2. Sürüm hakkında önceden bilgilendirmeniz gerekebilecek müşteriler var mı? Sürüm yayınlanırken olası bir hizmet kesintisi veya performans düşüşünden bahsetmem gerekir mi? Şahsen her zaman aşırı iletişim kurma ve tüm müşterilere herkese açık bir blogda veya benzer bir mekanda gelecek bir yayın veya bakım penceresi hakkında bilgi verme tarafında hata yapıyorum .

3. Serbest bırakmanın ters gitmesi durumunda beklenmedik durum planlarım nelerdir? Örneğin, sürüm kötü giderse, sistemi geri döndüğümüzde ve çevrimdışı olduğumuz zaman en aza indirgemek için sistemi geri yüklemeliyiz? Ve eğer öyleyse, bir sürümü geri alma adımları iyi bir şekilde belgelenmiş midir? Ya da sorunların ortaya çıkması durumunda sorunların giderilmesine yardımcı olmak için doğru kişileri yanımda veya el altında bulundurmam gerekir. Şahsen, herhangi bir sürümün planlamasına yaklaşmanın en iyi yolunun, sürümde bir şeyin yanlış gideceğini varsaymak olduğunu düşünüyorum. Bu şekilde kendimi bu konulardan bazılarını önceden düşünmeye zorladım.

Daha sonra, bir sürümün çalıştırılması söz konusu olduğunda, sorunsuz bir şekilde çalışmasını sağlamanın en iyi yollarından biri, karşılaştığınız her şeyi pratik yapmak, uygulamak, uygulamak ve belgelendirmektir.. Bu nedenle, yeni kodu üretime dağıtmadan önce, kodu önce güvenli, düzgün bir şekilde sanallaştırılmış bir hazırlama ortamına dağıtma alıştırması yapın. Üretime dağıtmaktan sorumlu olacak kişiyi, test dağıtımını evrelemeye getirin. Bunu elbise prova olarak düşünün ve gerçek olan bu gibi kendinizi yönetin. Yolun her adımında yaptığınız her şeyi belgeleyin; yürüttüğünüz her komutu, çalıştırdığınız herhangi bir SQL kodunu, değiştirdiğiniz dosyaları ve bunları nasıl değiştirdiğinizi ve yol boyunca her adım için prosedürün düzgün bir şekilde yürütülüp yürütülmediğini görmek için ne beklediğinizi belgelendirin. Bir tür sorunla karşılaşırsanız ve karşılaştığınızda, sorunu çözmek için ne yaptığınızı belgeleyin.

Ardından uygulama dağıtımı tamamlanır, notlarınızı gözden geçirin ve hataları ortadan kaldırmak için işlemi iyileştirip düzeltemeyeceğinize bakın. Sonra tekrar tekrar yapın . Bir sürümün yürütülmesi, "bu makineye giriş yapın, bu komutu yürütün; sonra veritabanına giriş yapın ve bu SQL komutunu yürütün; sonra ..."

Bir işlemin veya sürüm yönetimi ekibinin bir sürümün sorunsuz bir şekilde çalışmasına yardımcı olmak için yapabileceği şeyler yukarıda listelenmiştir. Ancak, bir sürümdeki riskleri en aza indirmeye yardımcı olmak için mühendislik ne yapabilir?

1. Sürümleri küçük tutun. Basitçe söylemek gerekirse, bir sürümün içerdiği kod seti seti ne kadar karmaşıksa, sürüm o kadar riskli hale gelir. Operasyon ekibinize, aynı zaman diliminde daha az sayıda büyük sürümden ziyade daha fazla sayıda küçük sürüm yayınlamayı planlayarak bir iyilik yapın.

2. Test, test, test. Kodunuzu yalnızca KG ortamınızda test etmeyin, yazılımınızı test etmek için hazırlama ortamını kullanın. Genellikle kodun kendisi ile çok az veya hiçbir ilgisi olmayan, ancak ortamın kendisinin (veya ikisinin bir karışımının) konfigürasyonunda yatan kök bir nedeni olan hatalar vardır. Bu sorunları bulmak için kodunuzu üretimi, yani sahnelemeyi yakından yansıtan bir ortamda test etmeniz gerekir.

Son olarak, bazen en önemli olan şeylerin yanlış gitmesini önlemek için yaptığımız şey değildir, ama yanlış gittiğinde kendimizi böyle yönetiriz. Bu nedenle, operasyonel şeffaflık konusunda şirketinizde bir kültür oluşturmanın önemli olduğunu düşünüyorum. Müşterilerden gelen sorunları gizlemeye çalışmayın, yakında olun. Operasyon ekibinizin şu anda farkında olduğu ve çözmeye çalıştığı sorunlar olup olmadığını müşterilere bildirmek için Twitter'ı aktif olarak kullanın ( Deniz Feneri bu harika!). Hizmetiniz için, müşterilerin bir sorun olup olmadığını görmek üzere başvurabilecekleri bir "durum" sayfası yayınlamayı düşünün ( TypePad buna harika bir örnek sunar). Alt satırda, her zaman aşırı iletişim tarafında hata. Müşterileriniz bunun için size teşekkür edecek.

Buradaki birçok yanıt zaten size özel çözümünüzü nasıl uygulayacağınızı söyler, ancak anlayabildiğim kadarıyla, gerçek sorun bir web sitesini düzgün bir şekilde taşıma / güncelleme değil. Arkasındaki tasarım / mimari kırılgan olabilir.

Bu doğruysa, sisteminizin mimarisini, yapılandırma ayarları değişse veya düzgün bir şekilde ayarlanmamış olsa bile düzgün çalışmaya devam edecek kadar sağlam olacak ve gerçekleşirse incelikle bozulacak şekilde ayarlamanız gerekir. İdeal olarak, yeni bir işlevsellik eklediyseniz veya eski işlevselliği yeni bir veritabanı sütunu gerektirecek şekilde değiştirdiyseniz, sütun eksik olsa bile siteniz çalışır (belki yeni işlevsellik olmadan veya eski işlevselliğin bozulmuş bir biçimiyle). . Müşteriniz para kaybetmemelidir - en kötüsü, koyduğunuz iyileştirmelerden yeni para almıyor olabilir.

Sisteminiz, yapılandırma ayarlarının bu tür ciddi sorunlara neden olabileceği kadar kırılgansa, program güncellemeleri sorunların tek kaynağı olmayacaktır - ve güncellemelerin nasıl güvenli bir şekilde yapılacağını bulmak sadece hata geldiğinde karşılaşacağınız hasarı artıracaktır. farklı bir kaynak.