Sürüm kontrol listeleri genellikle API'nin çalıştığını, kuyruğun boşaldığını ve kullanıcı arayüzünün yüklendiğini kanıtlar. Daha sonra yanlış ana bilgisayar adıyla bir onay e-postası gönderilir veya sıfırlama bağlantısı dünkü ortamı işaret eder. Bu boşluk, şimdi yayın yolunda küçük bir e-posta kontrolü tutmamın nedenidir. Süslü değil ama önlenebilir pek çok çöpten kurtarıyor.
Dev bir süitten bahsetmiyorum. Bu sürümde en önemli olan e-posta için tekrar oynatılabilir bir iş akışını kastediyorum: kaydolma, onaylama, parola sıfırlama, davet etme, kullanıcının görebileceği ve kırılması kolay olan her şey. Sahte bir e-posta adresi burada izole bir hedef olarak faydalıdır, ancak gerçek kazanç, kontrolü onun etrafında nasıl yapılandırdığınızla ilgilidir.
Sürüm kontrolleri neden e-posta regresyonlarını kaçırıyor?
Çoğu ekip e-postayı zaten bir yerlerde test ediyor. Sorun, bu testlerin genellikle sürümün kendisinden çok uzakta olmasıdır. Birim testleri şablonların oluşturulduğunu kanıtlar. Entegrasyon testleri bir olayın kuyruğa girebileceğini kanıtlıyor. Manuel QA, birisinin bir mesajı bir kez gördüğünü kanıtlar. Bunların hiçbiri sürüm sorusunu tam olarak yanıtlamıyor: Bu dağıtım şu anda doğru akış için, doğru hedefle doğru mesajı üretti mi?
Bu kulağa küçük geliyor ama yine de çok gerçek hataları yakalıyor:
Sistem Güvenliği
şablon oluşturmada eski ortam değişkenleri
eski bir mesajın tekrar oynatılmasıyla geciken işler
Uzmanların Görüşleri
Yanlış ana bilgisayarı kullanan onay bağlantıları
yeniden deneme hatasından sonra iki mesaj üreten bir olay
Önemli Gelişmeler
Bunlar, bir insan e-postayı tıklayana kadar her şeyin sağlıklı görünmesini sağlayan sinir bozucu gerilemelerdir. Bu hatayı daha önce de yapmıştım ve aksi takdirde sağlam boru hatlarını gözden kaçırmak garip bir şekilde kolaydır.
Hala gerçek sorunları yakalayan en küçük iş akışı
Nasıl Önlem Alınmalı?
Benim kuralım basit: Tek tetikleyici, tek yalıtılmış gelen kutusu, tek karar. Bir iş aynı anda altı e-posta türünü doğrulamaya çalışırsa sinyal çok hızlı bir şekilde bulanıklaşır. Küçük çeklere güvenmek daha ucuzdur ve bir şeyler ters gittiğinde yeniden yapılması daha kolaydır.
Bir serbest bırakma kapısı için genellikle dört şeyi iddia ederim:
Gelecekte Ne Bekleniyor?
Amaçlanan eylem tam olarak bir mesaj üretti. Konu ve alıcı daha eski bir çalışmayla değil, bu çalışmayla eşleşiyor. Ana CTA, mevcut ortam için beklenen ana bilgisayarı kullanır. Vücut hala amaçlanan adımı net bir şekilde iletmektedir.
Bu son kısım takımların kabul ettiğinden daha önemli. Aktarım yolu teknik olarak uygun olsa bile bozuk kopya hâlâ bozuk bir iş akışıdır.
Teknik Analiz
İlgili doğrulama için daha geniş bir model istiyorsanız, bu şablon düzeyindeki duman kontrolleri, e-posta doğrulamasını dar ve kullanışlı tutmanın güzel bir örneğidir. Yayınınız bir e-posta tıklamasından sonraki kullanıcı eylemlerine bağlıysa, onay bağlantısı iddiaları, onunla eşleştirmeyi sevdiğim türden odaklanmış takiplerdir.
Detaylar ve Etkileri
Ayrıca insanlar aceleleri olduğunda ve kalite kontrol için yalıtılmış bir gelen kutusuna ihtiyaç duyduklarında sahte e-posta adresi gibi kaba ifadeler ararlar. Dahili araçları bu şekilde adlandırmam ama runbook'ları ve belgeleri yazarken bu karmaşık arama amacını aklımda tutuyorum.
Sonuç ve Değerlendirme
Başarısızlıkların açıklanması kolay olsun diye kaydettiklerim
Serbest bırakma kontrolü titreşimlerle değil kanıtlarla başarısız olmalıdır. Başka bir mühendis iş çıktısını iki saat sonra açarsa, çok az bağlam değişimiyle ne olduğunu biliyor olmalıdır.
Varsayılan günlük alanlarım şunlardır:
çıkarılan birincil bağlantı ana bilgisayarı
varsa sağlayıcı mesaj kimliği
Bu, uygulama mantığını, teslimat gecikmesini ve donanım hatalarını ayırmak için yeterlidir. Bir mesaj asla ulaşmadığında nereden başlayacağınızı bilirsiniz. İkisi geldiğinde, muhtemelen yeniden denemeleri veya yinelenen etkinlikleri kovaladığınızı bilirsiniz. Ana bilgisayar hatalı olduğunda arama alanı çok daha küçülür. Basit gibi görünse de ekiplerin en sık atladığı kısım budur ve aslında yeterince açıklanmadığında kontrol "kesintili" gibi gelir.
Tekrar oynatılabilir kalan bir komut dosyası şekli
İş akışının neredeyse sıkıcı olmasını seviyorum:
RUN_ID = " $( date -u +%Y%m%dT%H%M%SZ ) " MAILBOX = "release- $RUN_ID @example.test" tetik_release_email " $MAILBOX " wait_for_message " $MAILBOX " 90 asset_message_count " $MAILBOX " 1assert_link_host " $MAILBOX " "staging.example.com" iddia_subject_contains " $MAILBOX " "Dağıtımınızı onaylayın" Tam ekran moduna girin Tam ekran modundan çıkın
Sıkıcı iyidir. Sıkıcı, bir sonraki kişinin bunu otuz saniye içinde okuyabilmesi ve başarısızlığın gerçek olup olmadığına karar verebilmesi anlamına gelir. Aynı zamanda, bir yapılandırma düzeltmesinden sonra iş akışının yeniden oynatılmasını da kolaylaştırır; bu, birçok sürüm aracının biraz fazla akıllı ve kırılgan hale geldiği yerdir.
Ayrıca veri yaşam döngüsünü kısa tutmaya çalışıyorum. Her çalıştırma için yalıtılmış bir gelen kutusu, kısa süreli saklama ve net günlükler çoğu ekip için yeterlidir. Bunun için çok büyük bir platforma ihtiyacınız yok. Baskı altındayken bile tahmin edilebilir şekilde davranan bir iş akışına ihtiyacınız var. sabahın yarısı biraz dağınık.
Bu CI'da mı yoksa manuel ön kontrol olarak mı yaşanmalı?
Her ikisi de işe yarayabilir. Tetikleyicinin belirleyici olduğu ve gelen kutusu araçlarının kararlı olduğu durumlarda CI'yı tercih ederim. Daha yüksek riskli sürümler veya dışarıya bağımlı akışlar için manuel ön kontrol hâlâ uygundur.
Ya e-posta sağlayıcınız bazen yavaşsa?
Makul bir zaman aşımı ayarlayın ve gerçek bekleme süresini kaydedin. Gecikme yaygınsa, bu yalnızca test gürültüsü değil, başlı başına yararlı bir sürüm bilgisidir.
Tüm vücudu doğrulamam gerekiyor mu?
Genellikle hayır. Yüksek sinyalli parçaları kontrol edin: alıcı, konu, ana CTA ve iş akışına özgü bir veya iki dize. Daha fazlası hızlı bir şekilde kırılgan hale gelebilir ve bu muhtemelen bir serbest bırakma kapısında istediğiniz şey değildir.
Zihinsel modelin tamamı budur: Çeki küçük, izole edilmiş ve açıklanması kolay tutun. İş akışı bu kadar küçük olduğunda ekipler aslında bunu devam ettiriyor ve bu, kağıt üzerinde mükemmel bir sistem oluşturmaktan daha önemli.
