Cypress Testlerini Docker, Buildkite ve CICD ile Entegre Etme #frontend@twiliosendgrid

Web uygulamalarımızın arka uçla beklendiği gibi çalıştığını doğrulamak için birçok uçtan uca (E2E) Cypress testi yazdık. Bu tarayıcı otomasyon testlerini yazdıktan sonra, kodu birleştirmeden ve belirli ortamlara dağıtmadan önce, bu Cypress testlerinin her zaman birim testlerimiz gibi bir şekilde çalıştırılmasını veya tetiklenmesini isteriz. Bu, sürekli entegrasyon (CI) sağlayıcımızla ve bu kapsayıcıları çalıştırmak için bulutta kullandığımız makinelerle entegre olmak için Cypress testlerimizi bir Docker kapsayıcısında çalıştırmayı istememize neden oldu.

Dağıtım akışları söz konusu olduğunda, CI sağlayıcımız olarak Buildkite kullanıyoruz. Bu, kodu pano boyunca taşımayı planladığımızda, bir Buildkite ardışık düzeninde uygulamamız için otomatikleştirilmiş adımlardan oluşan bir yapı oluşturmamızı sağlar. Daha fazla bağlam için, bir işlem hattı, genellikle bir uygulamanın deposuna bağlı olan ve burada derlemelere bakabileceğimiz veya derlemeleri belirli adımlarla, çekme istekleri oluşturduğunuzda, yeni kod değişikliklerini aktardığınızda, ana kod için birleştirmede ve farklı ortamlara dağıtırken çalıştırılması için tetikleyebildiğimiz bir yerdir. . Dağıtım, tetiklenen Cypress testleri ve bir zamanlamaya göre çalışan belirli Cypress testleri gibi ayrı amaçlar için birden çok işlem hattı oluşturuyoruz.

Bu blog gönderisi, daha önce Cypress testleri yazdığınızı ve bazı testlerin çalıştığını varsayıyor, ancak geliştirme ve dağıtım akışlarınızda bu testleri her zaman nasıl çalıştıracağınıza dair fikir edinmek istiyor. Bunun yerine Cypress testleri yazma hakkında daha fazla genel bakış istiyorsanız, bu önceki blog gönderisine göz atabilir ve çalıştıracak bir şeyiniz olduğunda bunu tekrar ziyaret edebilirsiniz.

Dağıtım hattımızda Docker Compose ve Buildkite ile nasıl yaptığımıza göz atarak, Cypress testlerini bir Docker kapsayıcısında CI sağlayıcınızla nasıl entegre edebileceğiniz konusunda size yol göstermeyi amaçlıyoruz. Bu fikirler, Cypress testlerini tetiklerken uygulanacak stratejiler, komutlar ve ortam değişkenleri için altyapınızda genişletilebilir.

Standart CICD akışımız

Standart geliştirme ve dağıtım akışımızda iki ardışık düzen kurduk:

1. İlki, kodu zorladığımız zaman için dağıtım adımlarımızı ele alır.
2. İkincisi, Cypress testlerimizin paralel olarak çalışmasını ve kaydedilmesini tetikler. Bunun başarısı veya başarısızlığı dağıtım hattını etkiler.

Dağıtım boru hattımızda, web uygulaması varlıklarımızı oluşturuyoruz, birim testleri çalıştırıyoruz ve her bir ortama dağıtmadan önce seçilen Cypress testlerini tetiklemek için adımlara sahibiz. Bir basmalı düğme konuşlandırma yeteneğini devre dışı bırakmadan önce geçtiklerinden emin oluyoruz. İkinci ardışık düzendeki bu tetiklenen Cypress testleri ayrıca bir Docker kapsayıcısında çalışır ve bir kayıt anahtarı aracılığıyla ücretli Cypress Dashboard'a bağlanır, böylece herhangi bir sorunda hata ayıklamak için bu Cypress testlerinden videolara, ekran görüntülerine ve konsol çıktılarına bakabiliriz.

Buildkite'ın seçme girdilerini kullanarak , bir dinamik tasarladık, kendi maceranızı seçin, böylece kullanıcılar hangi Cypress özellikli klasörlerin çalıştırılacağına karar vermek ve daha fazla kod yükledikçe doğrulamak için “Evet” veya “Hayır” seçebilirler. Tüm seçenekler için varsayılan yanıt "Hayır" olacaktır, ancak "Evet" değeri Cypress spec klasörünün glob yolu olacaktır.

Kod değişikliğimiz diğer sayfaları etkilemiyorsa, bazen tüm Cypress testlerini çalıştırmak istemiyoruz. Bunun yerine, yalnızca etkileneceğini bildiğimiz testleri tetiklemek istiyoruz. Ayrıca, tetiklediğimiz test sayısına bağlı olarak 0 ila 10 dakika arasında sürebilen Cypress testlerimizi çalıştırmayacak kadar kendimizi güvende hissettiğimiz için, acil bir hata sorunu için üretime hızlı bir düzeltme dağıtmamız gerekebilir. Bu kısım için hem görsel olarak hem de YML adımlarında örnek veriyoruz.

Ardından, seçilen “Evet” veya “Hayır” değerlerini ayrıştırmak için bu seçme adımından sonra çalıştırmak için runCypress.sh adlı kendi Bash betiğimizi uyguladık. Bunu, tetiklenen bir ardışık düzende bir Docker kapsayıcısında çalışan nihai Cypress komutumuza bir seçenek olarak --spec eklemek ve çalıştırmak için virgülle ayrılmış belirtim yollarının bir listesini oluşturmak için yapıyoruz. Oluşturulan özellik listesi gibi ortam değişkenlerini "CYPRESS_SPECS" içinde ve mevcut test ortamını "CYPRESS_TEST_ENV" içinde buildkite-agent pipeline upload "$DIRNAME"/triggerCypress.yml ile betiğin sonunda tetiklediğimiz boru hattında kullanmak üzere dışa aktarıyoruz. buildkite-agent pipeline upload "$DIRNAME"/triggerCypress.yml .

Bir "ASYNC" ortam değişkenini nasıl dışa aktardığımızı da fark etmiş olabilirsiniz. Buildkite'ta, başarı veya başarısızlık açısından, tetiklenen bir oluşturma adımının engelleyici veya engelleyici olmamasını seçebilirsiniz. "ASYNC" değerini true olarak ayarladıysak, ana dağıtım ardışık düzen adımlarımız çalışmaya devam edecek ve farklı bir ardışık düzende tetiklenen Cypress testlerinin bitmesini beklemeyecektir. İşlem hattının başarısı veya başarısızlığı, dağıtım hattının başarısını veya başarısızlığını etkilemez.

"ASYNC" öğesini false olarak ayarladıysak, farklı bir işlem hattında tetiklenen Cypress testleri bitene kadar ana dağıtım işlem hattı adımlarımız engellenir. Tetiklenen derlemenin başarısı veya başarısızlığı, daha sonra başladığı dağıtım işlem hattının genel başarısına veya başarısızlığına yol açar.

Kodumuz hala bir çekme isteği açık olan bir özellik dalındayken, daha fazla değişiklik göndermeyi, bazı Cypress testlerini tetiklemeyi ve işlerin nasıl davrandığını görmeyi seviyoruz. Ancak, yol boyunca potansiyel olarak daha fazla değişiklik olacağından, tetiklenen testler başarısız olursa, dağıtım ardışık düzen adımlarının geri kalanının çalışmasını her zaman engellemek istemiyoruz. Bu senaryoda, Cypress testleri başarısız olursa engellememek için “ASYNC”i false olarak ayarladık. Çekme talebimizi master ile birleştirip hazırlamaya dağıttığımız ancak üretime dağıtmadan önce Cypress testlerini tetiklemek istediğimiz durumda, Cypress testlerinin üretime geçmeden önce her zaman geçmesini istediğimizden “ASYNC”i true olarak ayarladık. .

runCypress.sh dosyasına geri dönersek, komut dosyasının, atanan ortam değişkeni değerleriyle triggerCypress.yml dosyasını çağırarak ikinci ardışık düzeni tetiklediğini hatırlıyoruz. triggerCypress.yml dosyası şuna benzer. "Tetikleme" adımının ve derleme mesajlarına değerlerin enterpolasyonunun hata ayıklama ve dinamik adım adları için yararlı olduğunu fark edeceksiniz.

Cypress testlerini dağıtım hattımızdan ayrı bir tetik ardışık hattına çalıştırmak için tetiklesek de, Cypress testlerini özel bir boru hattında bir programda çalıştırsak da, yalnızca ortam değişkeni değerlerini değiştirirken aynı adımları izler ve yeniden kullanırız.

Bu adımlar şunları içerir:

1. Docker görüntüsünü en son etiket ve benzersiz sürüm etiketiyle oluşturma
2. Docker görüntüsünü özel kayıt defterimize göndermek
3. Bir Docker kapsayıcısındaki ortam değişkeni değerlerimize dayalı Cypress testlerimizi çalıştırmak için aynı görüntüyü aşağı çekmek

Bu adımlar, aşağıdaki gibi bir pipeline.cypress.yml dosyasında özetlenmiştir:

Cypress testlerini çalıştırmak için tetiklediğimizde, Cypress tetikleme boru hattında ayrı bir yapı başlatacaktır. Yapının başarısına veya başarısızlığına bağlı olarak, Cypress test çalıştırması, ana dal yapıları için hazırlık aşamasından üretime geçerken üretime konuşlandırmamızı engeller veya bize izin verir.

“Triggered selvi/entegrasyon/…” adımına tıklamak, testlerin nasıl gittiğini görmek için sizi bu gibi bir görünümle tetiklenen ardışık düzenin yapısına götürecektir.

Docker parçasının nasıl bağlandığını merak ediyorsanız, Dockerfile.cypress ve docker-compose.cypress.yml boru hatlarımızdan dışa aktarılan bu ortam değişkenlerini kullanır ve ardından uygulamamızın package.json sağa işaret eden uygun Cypress komutunu kullanır. test ortamı ve seçilen özellik dosyalarının çalıştırılması. Aşağıdaki snippet'ler, daha esnek olmak için genişletebileceğiniz ve geliştirebileceğiniz genel yaklaşımımızı göstermektedir.


Her zamanki entegrasyon ve dağıtım döngülerimiz sırasında yürütülen testlerin dışında, özel Buildkite ardışık düzenleri oluşturduk. Bu işlem hatları, ön uç ve arka uç hizmetlerimizin doğru şekilde çalıştığından emin olmak için hazırlama ortamımıza karşı önemli testler için bir programa göre çalışır. Benzer işlem hattı adımlarını yeniden kullandık, Buildkite işlem hattının ayarlarında belirli ortam değişkeni değerlerini ayarladık ve programlanan bir zamanda çalışacak bir cron programı oluşturduk. Bu, testlerimizin ne kadar iyi çalıştığını ve aşağı yönde veya kendi kod zorlamalarımızdan kaynaklanan herhangi bir şeyin testlerin başarısız olmasına neden olup olmadığını izlemeye devam ederken, hazırlama ortamıyla ilgili birçok hatayı ve sorunu yakalamamıza yardımcı olur.

paralelleştirme

Operasyon ekibimiz tarafından oluşturulan yapı aracıları kuyruğumuzdan oluşturabileceğimiz AWS makinelerinin sayısından yararlanmak için paralelleştirme bayrağını da kullanırız. Bu paralelleştirme bayrağı ile Cypress, Buildkite'ın “paralellik” özelliğinde belirlediğimiz sayıya göre belirli sayıda makineyi otomatik olarak sihirli bir şekilde getirir.

Uygulama depolarımızdan biri için yaklaşık 5 dakikada 200'ün üzerinde test yapabildik.

Ardından, belirli bir derleme çalışması için testlerin her birinin kaydını tutarken tüm Cypress testlerini bu makineler arasında paralel çalışacak şekilde yayar. Bu, test çalıştırma sürelerimizi önemli ölçüde artırdı!

Cypress testlerinizi paralel hale getirirken bazı ipuçları:

• Optimum makine sayısı için Pano Hizmetindeki önerileri izleyin ve boru hatlarınızda esneklik için makine sayısının bir ortam değişkeninde ayarlanmasını sağlayın.
• Daha küçük test dosyalarına bölün, özellikle daha uzun süren testleri parçalara bölerek makineler arasında daha iyi paralel hale getirebiliriz.
• Cypress testlerinizin izole olduğundan ve birbirini etkilemediğinden veya birbirine bağlı olmadığından emin olun. Güncelleme, oluşturma veya silme ile ilgili akışlarla uğraşırken, testlerin birbirini durdurmasını ve yarış koşullarına girmesini önlemek için ayrı kullanıcılar ve veri kaynakları kullanın. Test dosyalarınız herhangi bir sırada çalışabilir, bu nedenle tüm testlerinizi çalıştırırken bunun bir sorun olmadığından emin olun.
• Buildkite için, parallel seçeneğe ek olarak Buildkite yapı kimliği ortam değişkeni değerini --ci-build-id seçeneğine geçirmeyi unutmayın, böylece makineler arasında testleri paralelleştirirken hangi benzersiz yapı çalışmasının ilişkilendirileceğini bilir.

İncelemek için:

Cypress testlerinizi Buildkite gibi CI sağlayıcınıza bağlamak için yapmanız gerekenler:

1. Gerekli Cypress temel görüntüsünü ve testleri belirli tarayıcılara karşı bir Node ortamında çalıştırmak için gereken bağımlılıkları kullanarak uygulama kodunuzla bir Docker görüntüsü oluşturun.
2. Docker resminizi belirli etiketlerle bir kayıt defterine itin
3. Daha sonraki bir adımda aynı resmi aşağı çekin
4. Cypress Dashboard Service kullanıyorsanız Cypress testlerinizi başsız modda ve kayıt tuşları ile çalıştırın.
5. Farklı ortam değişkeni değerleri ayarlayın ve bu Docker kapsayıcılarında belirli bir test ortamına karşı seçilen Cypress testlerini tetiklemek için Cypress için çalıştırdığınız komutlara takın.

Bu genel adımlar yeniden kullanılabilir ve bir zamanlamaya göre çalışan Cypress testlerine ve dağıtım işlem hatlarınıza ek olarak seçili tarayıcılara karşı testleri tetiklemek gibi diğer kullanım durumlarına uygulanabilir. Anahtar, CI sağlayıcınızın yeteneklerinden yararlanmak ve komutlarınızı ortam değişkeni değerlerine göre esnek ve yapılandırılabilir olacak şekilde ayarlamaktır.

Komutlarınızı, ortam değişkeni değerlerine göre esnek ve yapılandırılabilir olacak şekilde ayarlayın.

CI sağlayıcınızla Docker'da testlerinizi çalıştırdıktan sonra (ve Dashboard Hizmeti için ödeme yaparsanız), testlerinizi birden fazla makinede paralel hale getirme avantajından yararlanabilirsiniz. Herhangi bir testin birbirini etkilemesini önlemek için, mevcut testleri ve kaynakları diğerine bağımlı olmayacak şekilde değiştirmeniz gerekebilir.

Ayrıca, arka uç API'nizi doğrulamak için bir test paketi oluşturmak veya seçtiğiniz bir tarayıcıda çalıştırılacak testleri tetiklemek gibi kendiniz deneyebileceğiniz fikirleri de tartıştık. Ayrıca burada Cypress belgelerinde sürekli entegrasyon kurmanın daha fazla yolu vardır .

Ayrıca, geliştirme ortamlarınızın her zaman beklendiği gibi çalıştığından emin olmak için dağıtım akışları veya planlanmış aralıklarla bu Cypress testlerini çalıştırmak önemlidir. Cypress testlerimizin, aşağı yöndeki arka uç hizmetleriyle ilgili sorunları yakaladığı, bir şekilde kapalı veya değiştirilmiş, ön uç uygulama hatalarında tezahür ettiği sayısız zaman olmuştur. Özellikle yeni React kod değişikliklerini yayınladıktan sonra bizi web sayfalarımızdaki beklenmedik hatalardan kurtardılar.

Test ortamlarımızda geçen testleri sürdürmek ve başarısız test çalışmalarını özenle izlemek, daha az destek biletine ve üretimde daha mutlu müşterilere yol açar. Yeni kod değişikliklerini zorladığınızda sağlıklı ve istikrarlı bir Cypress testleri paketini çalışır durumda tutmak, işlerin iyi gittiğine dair daha fazla güven sağlar ve sizin ve ekiplerinizin Cypress testlerinizle aynı şeyi yapmanızı öneririz.

Cypress testleri hakkında daha fazla kaynak için aşağıdaki makalelere göz atın:

• E2E Testleri Yazarken Nelere Dikkat Edilmelidir?
• Selvi Testleri Yazmaya 1.000 Ayak Genel Bakış
• TypeScript Cypress Testlerinizdeki Her Şey
• Cypress Testlerinde E-posta Akışlarıyla Başa Çıkmak
• Cypress Testlerinizi Yapılandırma, Düzenleme ve Birleştirme Fikirleri