Bölüm 1: Web/Android
Dikkat: bu makale orijinal makalenin Rusçaya çevirisidir Ancak, Rusçaya çevrildiğinde anlamın bozulmasını önlemek için tüm resimler, bağlantılar, alıntılar ve terimler orijinal dilinde korunur. Size mutlu çalışma diliyorum!
Şu anda DevOps uzmanlığı BT endüstrisinde en çok talep gören uzmanlık alanlarından biridir. Popüler iş arama sitelerini açıp maaşa göre filtrelerseniz DevOps ile ilgili işlerin listenin başında yer aldığını göreceksiniz. Ancak bunun esas olarak 'Kıdemli' pozisyona atıfta bulunduğunun anlaşılması önemlidir; bu da adayın yüksek düzeyde beceri, teknoloji ve araç bilgisine sahip olduğu anlamına gelir. Bu aynı zamanda üretimin kesintisiz işleyişiyle ilgili yüksek derecede sorumluluğu da beraberinde getiriyor. Ancak DevOps'un ne olduğunu unutmaya başladık. Başlangıçta belirli bir kişi veya departman değildi. Bu terimin tanımlarına bakarsak metodoloji, uygulamalar, kültür felsefesi, kavram grubu vb. pek çok güzel ve doğru isim buluruz.
Uzmanlığım test otomasyon mühendisi (QA otomasyon mühendisi), ancak bunun yalnızca otomatik testler yazmak veya test çerçeve mimarisi geliştirmekle ilişkilendirilmemesi gerektiğine inanıyorum. 2020 yılında otomasyon altyapısı bilgisi de şarttır. Bu, hedefleriniz doğrultusunda testlerin yürütülmesinden sonuçların tüm paydaşlara sunulmasına kadar otomasyon sürecini kendiniz organize etmenize olanak tanır. Sonuç olarak DevOps becerileri işin tamamlanması için bir zorunluluktur. Ve bunların hepsi güzel ama maalesef bir sorun var (spoiler: bu makale bu sorunu basitleştirmeye çalışıyor). Önemli olan DevOps'un zor olmasıdır. Ve bu çok açık çünkü şirketler, yapılması kolay bir şeye çok fazla para ödemeyecekler... DevOps dünyasında, uzmanlaşılması gereken çok sayıda araç, terim ve uygulama var. Bu özellikle kariyerin başlangıcında zordur ve birikmiş teknik deneyime bağlıdır.
Kaynak:
Burada muhtemelen giriş kısmını bitirip bu yazının amacına odaklanacağız.
Bu makale ne hakkında?
Bu yazımda test otomasyon altyapısı oluşturma deneyimimi paylaşacağım. İnternette çeşitli araçlar ve bunların nasıl kullanılacağı hakkında pek çok bilgi kaynağı var ancak ben bunlara tamamen otomasyon bağlamında bakmak istiyorum. Pek çok otomasyon mühendisinin, geliştirilen testleri sizden başka kimsenin yürütmediği veya bunların bakımıyla ilgilenmediği duruma aşina olduğuna inanıyorum. Sonuç olarak testler güncelliğini yitirir ve bunları güncellemek için zaman harcamanız gerekir. Yine, kariyerin başlangıcında bu oldukça zor bir görev olabilir: Hangi araçların belirli bir sorunu ortadan kaldırmaya yardımcı olacağına, bunların nasıl seçileceğine, yapılandırılacağına ve bakımının yapılacağına akıllıca karar vermek. Bazı test uzmanları yardım için DevOps'a (insanlara) başvuruyor ve dürüst olalım, bu yaklaşım işe yarıyor. Çoğu durumda tüm bağımlılıkları göremediğimiz için bu tek seçenek olabilir. Ancak bildiğimiz gibi DevOps çok meşgul adamlar çünkü organizasyona/ekibe bağlı olarak tüm şirketin altyapısını, dağıtımını, izlemesini, mikro hizmetlerini ve diğer benzer görevleri düşünmek zorundalar. Genellikle olduğu gibi otomasyon bir öncelik değildir. Böyle bir durumda başından sonuna kadar üzerimize düşen her şeyi yapmaya çalışmalıyız. Bu, bağımlılıkları azaltacak, iş akışını hızlandıracak, becerilerimizi geliştirecek ve olup bitenlerin daha büyük resmini görmemizi sağlayacak.
Makale, en popüler ve popüler araçları sunmakta ve bunların bir otomasyon altyapısı oluşturmak için adım adım nasıl kullanılacağını göstermektedir. Her grup, kişisel deneyim yoluyla test edilmiş araçlarla temsil edilir. Ancak bu aynı şeyi kullanmanız gerektiği anlamına gelmez. Araçların kendileri önemli değildir; ortaya çıkarlar ve geçerliliğini yitirirler. Mühendislik görevimiz temel ilkeleri anlamaktır: neden bu araç grubuna ihtiyacımız var ve onların yardımıyla hangi iş problemlerini çözebiliriz. Bu nedenle her bölümün sonunda kuruluşunuzda kullanılabilecek benzer araçlara bağlantılar bırakıyorum.
Bu yazıda neler yok
Makalenin belirli araçlarla ilgili olmadığını bir kez daha tekrarlıyorum, bu nedenle belirli komutların belgelerinden ve açıklamalarından herhangi bir kod eki olmayacak. Ancak her bölümün sonuna detaylı çalışma için bağlantılar bırakıyorum.
Bu şu nedenle yapılır:
- bu materyali çeşitli kaynaklarda (belgeler, kitaplar, video kursları) bulmak çok kolaydır;
- daha derine inmeye başlarsak bu yazının 10, 20, 30 bölümünü yazmak zorunda kalacağız (planlar 2-3 iken);
- Aynı hedeflere ulaşmak için başka araçlar kullanmak isteyebileceğiniz için zamanınızı boşa harcamak istemiyorum.
Uygulama
Bu materyalin sadece okuyup unutulmasını değil, her okuyucu için faydalı olmasını gerçekten isterim. Herhangi bir çalışmada pratik çok önemli bir bileşendir. Bunun için hazırladım. Ayrıca yürüttüğünüz komutların satırlarını akılsızca kopyalamadığınızdan emin olmanız için sizi bekleyen ödevler de var.
Plan
adım
Teknoloji
Tools
1
Yerel çalıştırma (web/android demo testlerini hazırlayın ve yerel olarak çalıştırın)
Node.js, Selenyum, Appium
2
Sürüm kontrol sistemleri
Git
3
Konteynerizasyon
Docker, Selenyum ızgarası, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Bulut platformları
Google Bulut Platformu
6
orkestrasyon
Kubernetes
7
Kod olarak altyapı (IaC)
Terraform, Ansible
Her bölümün yapısı
Anlatımı net tutmak için her bölüm aşağıdaki ana hatlara göre açıklanmıştır:
- teknolojinin kısa açıklaması,
- Otomasyon altyapısı için değer,
- Altyapının mevcut durumunun gösterimi,
- çalışma bağlantıları,
- benzer araçlar.
1. Testleri yerel olarak çalıştırın
Teknolojinin kısa açıklaması
Bu, demo testlerini yerel olarak çalıştırmak ve geçtiklerini doğrulamak için yalnızca bir hazırlık adımıdır. Pratik kısımda Node.js kullanılıyor ancak programlama dili ve platformu da önemli değil ve şirketinizde kullanılanları kullanabilirsiniz.
Ancak otomasyon aracı olarak sırasıyla web platformları için Selenium WebDriver'ı ve Android platformu için Appium'u kullanmanızı öneririm, çünkü sonraki adımlarda özellikle bu araçlarla çalışacak şekilde uyarlanmış Docker görsellerini kullanacağız. Üstelik işin gerekliliklerine göre bu araçlar piyasada en çok talep gören araçlardır.
Fark etmiş olabileceğiniz gibi, yalnızca web ve Android testlerini değerlendiriyoruz. Maalesef iOS tamamen farklı bir hikaye (teşekkürler Apple). İlerleyen bölümlerde IOS ile ilgili çözüm ve uygulamaları sergilemeyi planlıyorum.
Otomasyon altyapısı için değer
Altyapı açısından bakıldığında yerel olarak çalışmanın hiçbir değeri yoktur. Yalnızca yerel tarayıcılarda ve simülatörlerde testlerin yerel makinede çalışıp çalışmadığını kontrol edersiniz. Ancak her durumda bu gerekli bir başlangıç noktasıdır.
Altyapının mevcut durumunun gösterimi
Keşfedilecek bağlantılar
Benzer araçlar
- Selenium/Appium testleriyle birlikte istediğiniz herhangi bir programlama dili;
- herhangi bir test;
- herhangi bir test koşucusu.
2. Sürüm kontrol sistemleri (Git)
Teknolojinin kısa açıklaması
Sürüm kontrolünün hem ekip içinde hem de bireysel olarak gelişimin son derece önemli bir parçası olduğunu söylersem bu hiç kimse için büyük bir açıklama olmayacaktır. Çeşitli kaynaklara dayanarak Git'in en popüler temsilci olduğunu söylemek yanlış olmaz. Sürüm kontrol sistemi, kod paylaşımı, sürümlerin saklanması, önceki dallara geri yükleme, proje geçmişinin izlenmesi ve yedekleme gibi birçok fayda sağlar. Her bir noktayı ayrıntılı olarak tartışmayacağız çünkü bu konuya çok aşina olduğunuzdan ve günlük işlerinizde kullandığınızdan eminim. Ancak aniden olmazsa, bu makaleyi okumaya ara vermenizi ve bu boşluğu mümkün olan en kısa sürede doldurmanızı öneririm.
Otomasyon altyapısı için değer
Ve burada makul bir soru sorabilirsiniz: “Neden bize Git'ten bahsediyor? Herkes bunu biliyor ve bunu hem geliştirme kodu hem de otomatik test kodu için kullanıyor." Kesinlikle haklısınız ama bu yazımızda altyapıdan bahsediyoruz ve bu bölüm bölüm 7: “Kod Olarak Altyapı (IaC)” için bir ön izleme görevi görüyor. Bizim için bu, test de dahil olmak üzere tüm altyapının kod biçiminde tanımlandığı anlamına gelir; böylece buna sürüm oluşturma sistemlerini de uygulayabilir ve geliştirme ve otomasyon kodunda olduğu gibi benzer avantajlar elde edebiliriz.
IaC'ye 7. Adımda daha ayrıntılı olarak bakacağız, ancak şimdi bile yerel bir depo oluşturarak Git'i yerel olarak kullanmaya başlayabilirsiniz. Altyapıya uzak bir depo eklediğimizde büyük resim genişleyecektir.
Altyapının mevcut durumunun gösterimi
Keşfedilecek bağlantılar
Benzer araçlar
3. Konteynerizasyon (Docker)
Teknolojinin kısa açıklaması
Konteyner taşımacılığının oyunun kurallarını nasıl değiştirdiğini göstermek için gelin birkaç on yıl geriye gidelim. O zamanlar insanlar uygulamaları çalıştırmak için sunucu makineleri satın alıp kullanıyorlardı. Ancak çoğu durumda gerekli başlangıç kaynakları önceden bilinmiyordu. Sonuç olarak şirketler pahalı, güçlü sunucuların satın alınmasına para harcadı ancak bu kapasitenin bir kısmı tam olarak kullanılamadı.
Evrimin bir sonraki aşaması, kullanılmayan kaynaklara para israfı sorununu çözen sanal makineler (VM'ler) oldu. Bu teknoloji, uygulamaların aynı sunucu içerisinde birbirinden bağımsız olarak çalıştırılmasına olanak tanıyarak tamamen yalıtılmış alan tahsis edilmesini sağladı. Ancak ne yazık ki her teknolojinin dezavantajları vardır. Bir VM'yi çalıştırmak, CPU, RAM, depolama tüketen ve işletim sistemine bağlı olarak lisans maliyetlerinin hesaba katılması gereken tam bir işletim sistemi gerektirir. Bu faktörler yükleme hızını etkiler ve taşınabilirliği zorlaştırır.
Ve şimdi konteynerleştirmeye geliyoruz. Konteynerler tam bir işletim sistemi kullanmadığından, bu teknoloji bir kez daha önceki sorunu çözüyor, bu da büyük miktarda kaynağı serbest bırakıyor ve taşınabilirlik için hızlı ve esnek bir çözüm sağlıyor.
Elbette konteyner taşımacılığı teknolojisi yeni bir şey değil ve ilk kez 70'lerin sonlarında tanıtıldı. O günlerde pek çok araştırma, geliştirme ve girişim yapıldı. Ancak bu teknolojiyi uyarlayan ve kitlelerin kolayca erişebilmesini sağlayan Docker'dı. Günümüzde konteynerlerden bahsettiğimizde çoğu durumda Docker'ı kastediyoruz. Docker konteynerlerinden bahsettiğimizde Linux konteynerlerini kastediyoruz. Container'ları çalıştırmak için Windows ve macOS sistemlerini kullanabiliriz ancak bu durumda ek bir katmanın ortaya çıktığını anlamak önemlidir. Örneğin, Mac'teki Docker, kapsayıcıları hafif bir Linux VM'sinde sessizce çalıştırır. Android emülatörlerini konteynerlerin içinde çalıştırmayı tartıştığımızda bu konuya geri döneceğiz, dolayısıyla burada daha ayrıntılı olarak tartışılması gereken çok önemli bir nüans var.
Otomasyon altyapısı için değer
Konteynerleştirme ve Docker'ın harika olduğunu öğrendik. Buna otomasyon bağlamında bakalım çünkü her araç veya teknolojinin bir sorunu çözmesi gerekir. Kullanıcı arayüzü testleri bağlamında test otomasyonunun bariz sorunlarını özetleyelim:
- Selenium'u ve özellikle Appium'u kurarken çok sayıda bağımlılık;
- tarayıcıların, simülatörlerin ve sürücülerin sürümleri arasındaki uyumluluk sorunları;
- paralel çalışma için özellikle kritik olan tarayıcılar/simülatörler için yalıtılmış alan eksikliği;
- Aynı anda 10, 50, 100 ve hatta 1000 tarayıcıyı çalıştırmanız gerekiyorsa yönetimi ve bakımı zordur.
Ancak Selenium en popüler otomasyon aracı ve Docker da en popüler kapsayıcılaştırma aracı olduğundan, birisinin yukarıda belirtilen sorunları çözmek için güçlü bir araç oluşturmak üzere bunları birleştirmeye çalışması şaşırtıcı olmamalıdır. Bu tür çözümleri daha ayrıntılı olarak ele alalım.
Docker'da Selenyum ızgarası
Bu araç, birden fazla tarayıcıyı birden fazla makinede çalıştırmak ve bunları merkezi bir merkezden yönetmek için Selenium dünyasında en popüler araçtır. Başlamak için en az 2 parçayı kaydetmeniz gerekir: Hub ve Düğüm(ler). Hub, testlerden gelen tüm istekleri alan ve bunları uygun Düğümlere dağıtan merkezi bir düğümdür. Her Düğüm için, örneğin istenen tarayıcıyı ve sürümünü belirterek belirli bir yapılandırma yapılandırabiliriz. Ancak yine de uyumlu tarayıcı sürücülerini kendimiz halletmemiz ve bunları istenen Düğümlere yüklememiz gerekiyor. Bu nedenle Selenium grid, Linux işletim sistemine yüklenemeyen tarayıcılarla çalışmamız gerektiği durumlar dışında saf haliyle kullanılmaz. Diğer tüm durumlar için önemli ölçüde esnek ve doğru bir çözüm, Selenium grid Hub ve Node'ları çalıştırmak için Docker görüntülerini kullanmak olacaktır. Bu yaklaşım, düğüm yönetimini büyük ölçüde basitleştirir, çünkü ihtiyacımız olan görüntüyü, zaten yüklü olan tarayıcıların ve sürücülerin uyumlu sürümleriyle seçebiliyoruz.
Kararlılıkla ilgili olumsuz değerlendirmelere rağmen, özellikle çok sayıda Düğümü paralel çalıştırırken Selenyum ızgarası, Selenyum testlerini paralel olarak çalıştırmak için hala en popüler araçtır. Bu araçta çeşitli darboğazlarla mücadele eden çeşitli iyileştirmelerin ve değişikliklerin açık kaynakta sürekli olarak ortaya çıktığını unutmamak önemlidir.
Web için Selenoid
Bu araç, kutudan çıktığı gibi çalıştığı ve birçok otomasyon mühendisinin hayatını çok daha kolaylaştırdığı için Selenyum dünyasında bir dönüm noktasıdır. Öncelikle bu Selenyum ızgarasının başka bir modifikasyonu değil. Bunun yerine geliştiriciler, Golang'da Selenium Hub'ın tamamen yeni bir sürümünü oluşturdu ve bu sürüm, çeşitli tarayıcılar için hafif Docker görüntüleri ile birleşerek test otomasyonunun geliştirilmesine ivme kazandırdı. Üstelik Selenium Grid söz konusu olduğunda gerekli tüm tarayıcıları ve sürümlerini önceden belirlememiz gerekiyor, bu da tek bir tarayıcıyla çalışırken sorun olmuyor. Ancak birden fazla desteklenen tarayıcı söz konusu olduğunda Selenoid, 'talep üzerine tarayıcı' özelliği sayesinde bir numaralı çözümdür. Bizden istenen tek şey, gerekli görselleri önceden tarayıcılarla indirmek ve Selenoid'in etkileşime girdiği konfigürasyon dosyasını güncellemektir. Selenoid testlerden talep aldıktan sonra istenilen tarayıcı ile istenilen konteyneri otomatik olarak başlatacaktır. Test tamamlandığında Selenoid konteyneri kullanımdan kaldıracak ve böylece gelecekteki istekler için kaynaklar serbest bırakılacak. Bu yaklaşım, Selenyum ızgarasında sıklıkla karşılaştığımız, iyi bilinen 'düğüm bozulması' sorununu tamamen ortadan kaldırır.
Ancak ne yazık ki Selenoid hala sihirli bir değnek değil. 'Talep üzerine tarayıcı' özelliğini aldık ancak 'talep üzerine kaynaklar' özelliği hâlâ mevcut değil. Selenoid'i kullanmak için onu fiziksel donanıma veya bir VM'ye dağıtmamız gerekir; bu da, kaç kaynağın tahsis edilmesi gerektiğini önceden bilmemiz gerektiği anlamına gelir. Sanırım bu, 10, 20 ve hatta 30 tarayıcıyı paralel olarak çalıştıran küçük projeler için sorun değil. Peki ya 100, 500, 1000 veya daha fazlasına ihtiyacımız olursa? Her zaman bu kadar çok kaynağın bakımını yapmak ve bunlar için ödeme yapmak hiç mantıklı değil. Bu makalenin 5. ve 6. bölümlerinde ölçeklendirmenize olanak tanıyan ve böylece şirket maliyetlerini önemli ölçüde azaltan çözümleri tartışacağız.
Android için Selenoid
Selenoid'in bir web otomasyon aracı olarak başarısından sonra insanlar Android için de benzer bir şey istedi. Ve oldu - Selenoid Android desteğiyle piyasaya sürüldü. Üst düzey kullanıcı açısından bakıldığında çalışma prensibi web otomasyonuna benzer. Tek fark, Selenoid'in tarayıcı kapları yerine Android emülatör kaplarını çalıştırmasıdır. Bana göre bu, Android testlerini paralel olarak çalıştırmak için şu anda en güçlü ücretsiz araçtır.
Bu aracın olumsuz yönlerinden bahsetmek istemiyorum çünkü gerçekten çok beğendim. Ancak yine de web otomasyonu için geçerli olan ve ölçeklendirmeyle ilişkili aynı dezavantajlar mevcuttur. Buna ek olarak, aracı ilk kez kuruyorsak sürpriz olabilecek bir sınırlamadan daha bahsetmemiz gerekiyor. Android imajlarını çalıştırmak için iç içe sanallaştırma desteğine sahip bir fiziksel makineye veya VM'ye ihtiyacımız var. Nasıl yapılır kılavuzunda bunun bir Linux VM'de nasıl etkinleştirileceğini gösteriyorum. Ancak macOS kullanıcısıysanız ve Selenoid'i yerel olarak dağıtmak istiyorsanız bu durumda Android testlerini çalıştırmak mümkün olmayacaktır. Ancak bir Linux VM'yi her zaman 'yuvalanmış sanallaştırma' yapılandırılmış şekilde yerel olarak çalıştırabilir ve Selenoid'i içeride dağıtabilirsiniz.
Altyapının mevcut durumunun gösterimi
Bu makale kapsamında altyapıyı göstermek için 2 araç ekleyeceğiz. Bunlar web testleri için Selenyum ızgarası ve Android testleri için Selenoid'dir. GitHub eğitiminde ayrıca web testlerini çalıştırmak için Selenoid'in nasıl kullanılacağını da göstereceğim.
Keşfedilecek bağlantılar
Benzer araçlar
- Başka konteynerleştirme araçları da var, ancak Docker en popüler olanıdır. Başka bir şey denemek istiyorsanız Selenyum testlerini paralel olarak çalıştırmak için ele aldığımız araçların kutudan çıktığı anda çalışmayacağını unutmayın.
- Daha önce de söylediğimiz gibi Selenyum ızgarasının birçok modifikasyonu vardır;.
4.CI/CD
Teknolojinin kısa açıklaması
Sürekli entegrasyon uygulaması geliştirmede oldukça popülerdir ve sürüm kontrol sistemleriyle eşdeğerdir. Buna rağmen terminolojide bir karışıklık olduğunu hissediyorum. Bu paragrafta bu teknolojinin 3 modifikasyonunu kendi bakış açımdan anlatmak istiyorum. İnternette farklı yorumlara sahip birçok makale bulacaksınız ve görüşlerinizin farklı olması kesinlikle normaldir. En önemlisi meslektaşlarınızla aynı sayfada olmanızdır.
Yani 3 terim vardır: CI - Sürekli Entegrasyon, CD - Sürekli Teslimat ve yine CD - Sürekli Dağıtım. (Aşağıda bu terimleri İngilizce olarak kullanacağım). Her değişiklik, geliştirme sürecinize birkaç ek adım ekler. Ama kelime sürekli (sürekli) en önemli şeydir. Bu bağlamda, baştan sona, kesintisiz veya manuel müdahale olmadan gerçekleşen bir şeyi kastediyoruz. Bu bağlamda CI & CD ve CD'ye bakalım.
- Sürekli Entegrasyon bu evrimin ilk adımıdır. Yeni kodu sunucuya gönderdikten sonra, değişikliklerimizin tamam olduğuna dair hızlı bir geri bildirim almayı bekliyoruz. Tipik olarak CI, statik kod analiz araçlarının ve birim/dahili API testlerinin çalıştırılmasını içerir. Bu, kodumuz hakkında birkaç saniye/dakika içinde bilgi edinmemize olanak tanır.
- Sürekli Teslim entegrasyon/UI testlerini yürüttüğümüz daha ileri bir adımdır. Ancak bu aşamada CI kadar hızlı sonuç alamıyoruz. İlk olarak, bu tür testlerin tamamlanması daha uzun sürer. İkinci olarak, başlatmadan önce değişikliklerimizi test/hazırlama ortamına dağıtmalıyız. Üstelik mobil geliştirmeden bahsediyorsak, uygulamamızın yapısını oluşturmak için ek bir adım ortaya çıkıyor.
- Sürekli Dağıtım önceki aşamalarda tüm kabul testlerinin geçilmesi durumunda değişikliklerimizi otomatik olarak üretime yayınlayacağımızı varsayar. Buna ek olarak, sürüm aşamasından sonra üretimde duman testleri yapmak ve ilgilendiğiniz ölçümleri toplamak gibi çeşitli aşamaları yapılandırabilirsiniz. Sürekli Dağıtım yalnızca otomatik testlerin iyi bir şekilde kapsanması durumunda mümkündür. Test dahil herhangi bir manuel müdahale gerekiyorsa, bu artık geçerli değildir. Sürekli (sürekli). O halde boru hattımızın yalnızca Sürekli Teslimat uygulamasına uygun olduğunu söyleyebiliriz.
Otomasyon altyapısı için değer
Bu bölümde uçtan uca UI testlerinden bahsettiğimizde bunun, değişikliklerimizi ve ilgili hizmetlerimizi test ortamlarına dağıtmamız gerektiği anlamına geldiğini açıklığa kavuşturmalıyım. Sürekli Entegrasyon - süreç bu görev için geçerli değildir ve en azından Sürekli Teslimat uygulamalarını uygulamaya özen göstermeliyiz. Sürekli Dağıtım, eğer bunları üretimde çalıştıracaksak, kullanıcı arayüzü testleri bağlamında da anlamlıdır.
Mimari değişimin resmine bakmadan önce GitLab CI hakkında birkaç söz söylemek istiyorum. Diğer CI/CD araçlarının aksine GitLab, uzak bir depo ve diğer birçok ek özellik sağlar. Bu nedenle GitLab, CI'dan daha fazlasıdır. Kaynak kodu yönetimi, Çevik yönetim, CI/CD ardışık düzenleri, günlük kaydı araçları ve kullanıma hazır ölçüm koleksiyonunu içerir. GitLab mimarisi Gitlab CI/CD ve GitLab Runner'dan oluşur. İşte resmi web sitesinden kısa bir açıklama:
Gitlab CI/CD, durumunu bir veritabanında saklayan, projeleri/derlemeleri yöneten ve bir kullanıcı arayüzü sağlayan API'ye sahip bir web uygulamasıdır. GitLab Runner, derlemeleri işleyen bir uygulamadır. Ayrı olarak dağıtılabilir ve bir API aracılığıyla GitLab CI/CD ile birlikte çalışır. Çalışan testler için hem Gitlab örneğine hem de Runner'a ihtiyacınız var.
Altyapının mevcut durumunun gösterimi
Keşfedilecek bağlantılar
Benzer araçlar
- Ve bircok digerleri
5. Bulut platformları
Teknolojinin kısa açıklaması
Bu bölümde 'genel bulutlar' adı verilen popüler bir trendden bahsedeceğiz. Yukarıda açıklanan sanallaştırma ve konteynerleştirme teknolojilerinin sağladığı muazzam faydalara rağmen, hala bilgi işlem kaynaklarına ihtiyacımız var. Şirketler pahalı sunucular satın alıyor veya veri merkezleri kiralıyor ancak bu durumda ne kadar kaynağa ihtiyaç duyacağımızı, bunları 24/7 kullanıp kullanmayacağımızı ve hangi amaçlarla kullanacağımıza dair (bazen gerçekçi olmayan) hesaplamalar yapmak gerekiyor. Örneğin üretim XNUMX/XNUMX çalışan bir sunucuya ihtiyaç duyuyor ancak çalışma saatleri dışında test yapmak için de benzer kaynaklara ihtiyacımız var mı? Bu aynı zamanda gerçekleştirilen testin türüne de bağlıdır. Ertesi gün sonuç alabilmek için mesai saatleri dışında yapmayı planladığımız yük/stres testleri buna bir örnek olabilir. Ancak uçtan uca otomatikleştirilmiş testler ve özellikle manuel test ortamları için kesinlikle XNUMX/XNUMX sunucu kullanılabilirliği gerekli değildir. Bu gibi durumlarda, talep üzerine ihtiyaç duyulan kadar kaynak elde etmek, kullanmak ve ihtiyaç kalmadığında ödemeyi bırakmak iyi olacaktır. Üstelik birkaç fare tıklaması yaparak veya birkaç komut dosyasını çalıştırarak bunları anında almak harika olurdu. Genel bulutlar bunun için kullanılıyor. Tanıma bakalım:
“Genel bulut, üçüncü taraf sağlayıcılar tarafından genel İnternet üzerinden sunulan ve bunları kullanmak veya satın almak isteyen herkesin kullanımına sunan bilgi işlem hizmetleri olarak tanımlanıyor. Ücretsiz olabilirler veya isteğe bağlı olarak satılabilirler; böylece müşterilerin tükettikleri CPU döngüleri, depolama alanı veya bant genişliği için yalnızca kullanım başına ödeme yapmalarına olanak sağlanır."
Halka açık bulutların pahalı olduğuna dair bir görüş var. Ancak onların temel fikri şirket maliyetlerini azaltmaktır. Daha önce de belirtildiği gibi, genel bulutlar, kaynakları talep üzerine almanıza ve yalnızca onları kullandığınız süre için ödeme yapmanıza olanak tanır. Ayrıca bazen çalışanların maaş aldığını ve uzmanların da pahalı bir kaynak olduğunu unutuyoruz. Genel bulutların altyapı desteğini çok daha kolay hale getirerek mühendislerin daha önemli görevlere odaklanmasına olanak sağladığı dikkate alınmalıdır.
Otomasyon altyapısı için değer
Uçtan uca kullanıcı arayüzü testleri için hangi spesifik kaynaklara ihtiyacımız var? Temel olarak bunlar, tarayıcıları ve emülatörleri çalıştırmak için kullanılan sanal makineler veya kümelerdir (sonraki bölümde Kubernetes hakkında konuşacağız). Aynı anda ne kadar çok tarayıcı ve emülatör çalıştırmak istersek, o kadar fazla CPU ve bellek gerekir ve bunun için de o kadar fazla para ödemek zorunda kalırız. Bu nedenle, test otomasyonu bağlamında genel bulutlar, çok sayıda (100, 200, 1000...) tarayıcıyı/emülatörü isteğe bağlı olarak çalıştırmamıza, test sonuçlarını olabildiğince hızlı almamıza ve bu kadar yoğun kaynak kullanan cihazlar için ödeme yapmamıza olanak tanıyor. güç.
En popüler bulut sağlayıcıları Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform'dur (GCP). Nasıl yapılır kılavuzunda GCP'nin nasıl kullanılacağına ilişkin örnekler verilmektedir ancak genel olarak otomasyon görevleri için ne kullandığınız önemli değildir. Hepsi yaklaşık olarak aynı işlevselliği sağlar. Tipik olarak, bir sağlayıcı seçmek için yönetim, şirketin tüm altyapısına ve iş gereksinimlerine odaklanır ve bu, bu makalenin kapsamı dışındadır. Otomasyon mühendisleri için, bulut sağlayıcılarının kullanımını Sauce Labs, TarayıcıStack, BitBar vb. gibi özellikle test amaçlı bulut platformlarının kullanımıyla karşılaştırmak daha ilginç olacaktır. Öyleyse biz de yapalım! Bana göre Sauce Labs en ünlü bulut test çiftliğidir, bu yüzden karşılaştırma için onu kullandım.
Otomasyon amacıyla GCP ve Sos Laboratuvarları:
Aynı anda 8 web testi ve 8 Android testi çalıştırmamız gerektiğini düşünelim. Bunun için GCP kullanacağız ve Selenoid ile 2 adet sanal makine çalıştıracağız. İlkinde tarayıcılarla 8 konteyner oluşturacağız. İkincisinde emülatörlü 8 kap var. Şimdi fiyatlara bir göz atalım:
Chrome ile bir kapsayıcıyı çalıştırmak için ihtiyacımız var n1-standart-1 araba. Android durumunda olacak n1-standart-4 bir emülatör için. Aslında daha esnek ve daha ucuz bir yol, CPU/Bellek için belirli kullanıcı değerleri ayarlamaktır ancak şu anda bu, Sauce Labs ile karşılaştırma açısından önemli değildir.
İşte Sos Laboratuvarlarını kullanma tarifeleri:
Farkı zaten fark ettiğinize inanıyorum, ancak yine de görevimiz için hesaplamaları içeren bir tablo sunacağım:
Gerekli kaynaklar
Aylık
Çalışma saatleri(8:8 - XNUMX:XNUMX)
Çalışma saatleri+ Öncelikli
Web için GCP
n1-standart-1 x 8 = n1-standart-8
$194.18
23 gün * 12 saat * 0.38 = 104.88 ABD doları
23 gün * 12 saat * 0.08 = 22.08 ABD doları
Web için Sos Laboratuvarları
Virtual Cloud8 paralel testleri
$1.559
-
-
Android için GCP
n1-standart-4 x 8: n1-standart-16
$776.72
23 gün * 12 saat * 1.52 = 419.52 ABD doları
23 gün * 12 saat * 0.32 = 88.32 ABD doları
Android için Sos Laboratuvarları
Real Device Cloud 8 paralel testleri
$1.999
-
-
Gördüğünüz gibi, özellikle testleri yalnızca on iki saatlik bir çalışma süresinde çalıştırıyorsanız, maliyet farkı çok büyük. Ancak öncelikli makineler kullanırsanız maliyetleri daha da azaltabilirsiniz. Nedir?
Öncelikli VM, normal örneklerden çok daha düşük bir fiyata oluşturup çalıştırabileceğiniz bir örnektir. Ancak Compute Engine, diğer görevler için bu kaynaklara erişim gerektiriyorsa bu örnekleri sonlandırabilir (önleyebilir). Öncelikli örnekler Compute Engine kapasitesinin üzerinde olduğundan kullanılabilirlikleri kullanıma göre değişir.
Uygulamalarınız hataya dayanıklıysa ve olası örnek ön alımlarına dayanabiliyorsa öncelikli örnekler Compute Engine maliyetlerinizi önemli ölçüde azaltabilir. Örneğin, toplu işleme işleri öncelikli örneklerde çalıştırılabilir. Bu örneklerden bazıları işlem sırasında sona ererse iş yavaşlar ancak tamamen durmaz. Öncelikli bulut sunucuları, toplu işleme görevlerinizi mevcut bulut sunucularınıza ek iş yükü yüklemeden ve ek normal bulut sunucuları için tam ücret ödemenizi gerektirmeden tamamlar.
Ve hâlâ bitmedi! Gerçekte hiç kimsenin ara vermeden 12 saat boyunca test yapmadığından eminim. Eğer öyleyse, ihtiyaç duyulmadığında sanal makineleri otomatik olarak başlatıp durdurabilirsiniz. Gerçek kullanım süresi günde 6 saate düşürülebilir. Daha sonra görevimiz kapsamındaki ödeme 11 tarayıcı için ayda 8 dolara düşecek. Bu harika değil mi? Ancak öncelikli makinelerde dikkatli olmalı ve kesintilere ve istikrarsızlığa karşı hazırlıklı olmalıyız, ancak bu durumlar yazılımda sağlanıp halledilebilir. Buna değer!
Ancak hiçbir şekilde 'bulut test çiftliklerini asla kullanmayın' demiyorum. Bir takım avantajları var. Her şeyden önce, bu yalnızca bir sanal makine değil, aynı zamanda bir dizi kullanıma hazır işlevselliğe sahip tam teşekküllü bir test otomasyon çözümüdür: uzaktan erişim, günlükler, ekran görüntüleri, video kaydı, çeşitli tarayıcılar ve fiziksel mobil cihazlar. Çoğu durumda bu önemli bir şık alternatif olabilir. Test platformları, genel bulutların yalnızca Linux/Windows sistemleri sunabildiği IOS otomasyonu için özellikle kullanışlıdır. Ancak ilerleyen yazılarımızda iOS’tan bahsedeceğiz. Her zaman duruma bakmanızı ve görevlerden başlamanızı öneririm: bazı durumlarda genel bulutları kullanmak daha ucuz ve daha verimlidir, diğerlerinde ise test platformları kesinlikle harcanan paraya değer.
Altyapının mevcut durumunun gösterimi
Keşfedilecek bağlantılar
Benzer araçlar:
6. Düzenleme
Teknolojinin kısa açıklaması
İyi haberlerim var; neredeyse makalenin sonuna geldik! Şu anda otomasyon altyapımız, GitLab CI aracılığıyla paralel olarak Docker özellikli araçları (Selenium grid ve Selenoid) kullanarak yürüttüğümüz web ve Android testlerinden oluşuyor. Ayrıca, konteynerleri tarayıcılar ve emülatörlerle barındırmak için GCP aracılığıyla oluşturulan sanal makineleri kullanıyoruz. Maliyetleri azaltmak için bu sanal makineleri yalnızca talep üzerine başlatıyoruz ve test yapılmadığı zamanlarda durduruyoruz. Altyapımızı geliştirebilecek başka bir şey var mı? Cevap Evet! Kubernetes (K8s) ile tanışın!
Öncelikle orkestrasyon, küme ve Kubernetes kelimelerinin birbirleriyle nasıl ilişkili olduğuna bakalım. Yüksek düzeyde orkestrasyon, uygulamaları dağıtan ve yöneten sistemdir. Test otomasyonu için konteynerli uygulamalar Selenyum ızgarası ve Selenoid'dir. Docker ve K8'ler birbirini tamamlıyor. Birincisi uygulama dağıtımı için, ikincisi ise orkestrasyon için kullanılır. Buna karşılık K8'ler bir kümedir. Kümenin görevi, VM'leri Düğümler olarak kullanmaktır; bu, çeşitli işlevleri, programları ve hizmetleri tek bir sunucuya (küme) yüklemenize olanak tanır. Düğümlerden herhangi birinin arızalanması durumunda diğer Düğümler devreye girecek ve bu da uygulamamızın kesintisiz çalışmasını sağlayacaktır. Buna ek olarak K8s, ölçeklendirmeyle ilgili önemli bir işlevselliğe sahiptir; bu sayede yüke ve belirlenen limitlere göre optimum kaynak miktarını otomatik olarak elde ederiz.
Aslında Kubernetes'i sıfırdan manuel olarak dağıtmak hiç de önemsiz bir iş değil. Ünlü "Kubernetes The Hard Way" nasıl yapılır kılavuzunun bağlantısını bırakacağım, eğer ilgileniyorsanız pratik yapabilirsiniz. Ancak neyse ki alternatif yöntemler ve araçlar var. En kolay yol, GCP'de birkaç tıklamayla hazır bir küme elde etmenize olanak tanıyan Google Kubernetes Engine'i (GKE) kullanmaktır. Öğrenmeye başlamak için bu yaklaşımı kullanmanızı öneririm, çünkü bu, dahili bileşenlerin birbiriyle nasıl entegre edilmesi gerektiğini öğrenmek yerine K8'leri görevleriniz için nasıl kullanacağınızı öğrenmeye odaklanmanıza olanak tanır.
Otomasyon altyapısı için değer
K8'lerin sağladığı birkaç önemli özelliğe bir göz atalım:
- uygulama dağıtımı: VM'ler yerine çok düğümlü bir kümenin kullanılması;
- dinamik ölçeklendirme: yalnızca talep üzerine kullanılan kaynakların maliyetini azaltır;
- kendi kendini iyileştirme: bölmelerin otomatik olarak kurtarılması (bunun sonucunda kaplar da geri yüklenir);
- kesinti olmadan güncellemelerin kullanıma sunulması ve değişikliklerin geri alınması: güncelleme araçları, tarayıcılar ve emülatörler mevcut kullanıcıların çalışmalarını kesintiye uğratmaz
Ancak K8'ler hala sihirli bir değnek değil. Düşündüğümüz araçlar (Selenyum ızgarası, Selenoid) bağlamındaki tüm avantajları ve sınırlamaları anlamak için K8'lerin yapısını kısaca tartışacağız. Küme iki tür Düğüm içerir: Ana Düğümler ve Çalışan Düğümler. Ana Düğümler yönetim, dağıtım ve planlama kararlarından sorumludur. Çalışan düğümleri uygulamaların başlatıldığı yerdir. Düğümler ayrıca bir kapsayıcı çalışma zamanı ortamı içerir. Bizim durumumuzda bu, konteynerle ilgili işlemlerden sorumlu olan Docker'dır. Ancak alternatif çözümler de var, örneğin. Ölçeklendirmenin veya kendi kendini iyileştirmenin doğrudan kapsayıcılara uygulanmadığını anlamak önemlidir. Bu, sırasıyla kaplar içeren bölmelerin sayısını ekleyerek/azaltarak uygulanır (genellikle bölme başına bir kap, ancak göreve bağlı olarak daha fazla olabilir). Üst düzey hiyerarşi, içinde kapların yükseltildiği bölmelerin bulunduğu çalışan düğümlerden oluşur.
Ölçeklendirme özelliği çok önemlidir ve bir küme düğüm havuzu içindeki düğümlere ve bir düğüm içindeki bölmelere uygulanabilir. Hem düğümlere hem de bölmelere uygulanan 2 tür ölçeklendirme vardır. İlk tür yataydır; ölçeklendirme, düğüm/bölme sayısının arttırılmasıyla gerçekleşir. Bu tip daha çok tercih edilir. İkinci tip buna göre dikeydir. Ölçeklendirme, düğümlerin/podların sayısını değil, boyutunu artırarak gerçekleştirilir.
Şimdi yukarıdaki terimler bağlamında araçlarımıza bakalım.
Selenyum ızgarası
Daha önce de belirtildiği gibi Selenyum ızgarası çok popüler bir araçtır ve konteynere alınmış olması sürpriz değildir. Bu nedenle Selenyum ızgarasının K8'lerde konuşlandırılması şaşırtıcı değil. Bunun nasıl yapılacağına dair bir örnek resmi K8s deposunda bulunabilir. Her zamanki gibi bölümün sonuna bağlantılar ekliyorum. Ayrıca nasıl yapılır kılavuzunda bunun Terraform'da nasıl yapılacağı gösterilmektedir. Tarayıcı kapsayıcılarını içeren bölmelerin sayısının nasıl ölçeklendirileceğine ilişkin talimatlar da vardır. Ancak K8'ler bağlamında otomatik ölçeklendirme işlevi hala tam olarak açık bir görev değil. Çalışmaya başladığımda herhangi bir pratik rehberlik veya öneri bulamadım. DevOps ekibinin desteğiyle yapılan birçok çalışma ve deneyden sonra, gerekli tarayıcıların tek bir çalışan düğümünde yer alan tek bir bölmede yer aldığı konteynerleri yükseltme yaklaşımını seçtik. Bu yöntem, düğümlerin sayısını artırarak yatay ölçeklendirme stratejisini uygulamamıza olanak tanır. Bunun gelecekte değişeceğini umuyorum ve özellikle değişen iç mimariye sahip Selenium grid 4'ün piyasaya sürülmesinden sonra, daha iyi yaklaşımların ve hazır çözümlerin giderek daha fazla tanımını göreceğiz.
Selenoid:
K8'lerde selenoid dağıtımı şu anda en büyük hayal kırıklığıdır. Uyumlu değiller. Teorik olarak, bir bölmenin içinde bir Selenoid kabı yükseltebiliriz, ancak Selenoid tarayıcılarla kapları başlatmaya başladığında, bunlar hala aynı bölmenin içinde olacaktır. Bu, ölçeklendirmeyi imkansız hale getirir ve sonuç olarak Selenoid'in küme içindeki çalışması, sanal makine içindeki çalışmadan farklı olmayacaktır. Hikayenin sonu.
Ay:
Selenoid ile çalışırken bu darboğazı bilen geliştiriciler, Moon adında daha güçlü bir araç yayınladılar. Bu araç başlangıçta Kubernetes ile çalışacak şekilde tasarlandı ve sonuç olarak otomatik ölçeklendirme özelliği kullanılabilir ve kullanılmalıdır. Üstelik şu anda şunu söyleyebilirim ki sadece Kutudan çıktığı haliyle yerel K8 küme desteğine sahip olan Selenyum dünyasında bir araç (artık mevcut değil, sonraki araca bakın ). Moon'un bu desteği sağlayan temel özellikleri şunlardır:
Tamamen vatansız. Selenoid, halihazırda çalışmakta olan tarayıcı oturumları hakkındaki bilgileri hafızada saklar. Herhangi bir nedenle süreç çökerse, çalışan tüm oturumlar kaybolur. Ay'ın aksine bir iç durumu yoktur ve veri merkezleri arasında kopyalanabilir. Bir veya daha fazla kopya çökse bile tarayıcı oturumları canlı kalır.
Yani Moon harika bir çözüm ama bir sorun var: Ücretsiz değil. Fiyat seans sayısına bağlıdır. Yalnızca 0-4 seansı ücretsiz olarak çalıştırabilirsiniz, bu da pek kullanışlı değildir. Ancak beşinci seanstan itibaren her biri için 5$ ödemeniz gerekecek. Durum şirketten şirkete farklılık gösterebilir ama bizim durumumuzda Moon'u kullanmak anlamsız. Yukarıda anlattığım gibi isteğe göre VM'leri Selenium Grid ile çalıştırabilir veya Cluster'daki Node sayısını arttırabiliriz. Yaklaşık bir işlem hattı için 500 tarayıcı başlatıyoruz ve testler tamamlandıktan sonra tüm kaynakları durduruyoruz. Moon'u kullansaydık, testleri ne sıklıkta yaparsak yapalım, ayda 500 x 5 = 2500 ABD doları daha ödemek zorunda kalırdık. Tekrar ediyorum, Moon'u kullanmayın demiyorum. Görevleriniz için bu vazgeçilmez bir çözüm olabilir; örneğin kuruluşunuzda çok sayıda projeniz/ekibiniz varsa ve herkes için devasa bir ortak kümeye ihtiyacınız varsa. Her zaman olduğu gibi sonuna bir bağlantı bırakıyorum ve göreviniz bağlamında gerekli tüm hesaplamaları yapmanızı öneriyorum.
Callisto(Dikkat! Bu orijinal makalede yer almamaktadır ve yalnızca Rusça çeviride yer almaktadır.)
Söylediğim gibi Selenyum çok popüler bir araç ve BT alanı çok hızlı gelişiyor. Çeviri üzerinde çalışırken, internette Callisto adında yeni ve gelecek vaat eden bir araç belirdi (merhaba Cypress ve diğer Selenium katilleri). Yerel olarak K8'lerle çalışır ve Selenoid kaplarını Düğümler arasında dağıtılmış bölmeler halinde çalıştırmanıza olanak tanır. Otomatik ölçeklendirme dahil her şey kutudan çıktığı gibi çalışır. Harika ama test edilmesi gerekiyor. Bu aracı zaten dağıtmayı ve birkaç deneme yapmayı başardım. Ancak sonuç çıkarmak için henüz çok erken, uzun mesafelerden sonuçlar aldıktan sonra belki gelecek makalelerde bir inceleme yaparım. Şimdilik yalnızca bağımsız araştırmalar için bağlantılar bırakıyorum.
Altyapının mevcut durumunun gösterimi
Keşfedilecek bağlantılar
Benzer araçlar
7. Kod Olarak Altyapı (IaC)
Teknolojinin kısa açıklaması
Ve şimdi son bölüme geliyoruz. Genellikle bu teknoloji ve ilgili görevler otomasyon mühendislerinin sorumluluğunda değildir. Ve bunun nedenleri var. İlk olarak, birçok kuruluşta altyapı sorunları DevOps departmanının kontrolü altındadır ve geliştirme ekipleri, boru hattını neyin çalıştırdığı ve onunla bağlantılı her şeyin nasıl desteklenmesi gerektiğiyle pek ilgilenmez. İkinci olarak, dürüst olalım, Kod Olarak Altyapı (IaC) uygulaması hala pek çok şirkette benimsenmemiştir. Ancak kesinlikle popüler bir trend haline geldi ve onunla ilgili süreçlere, yaklaşımlara ve araçlara dahil olmaya çalışmak önemli. Veya en azından güncel kalın.
Bu yaklaşımı kullanma motivasyonuyla başlayalım. GitlabCI'da testler yürütmek için en azından Gitlab Runner'ı çalıştıracak kaynaklara ihtiyacımız olacağını zaten tartışmıştık. Konteynerleri tarayıcılar/emülatörlerle çalıştırmak için bir VM veya küme ayırmamız gerekir. Kaynakları test etmenin yanı sıra, veritabanlarını, otomatik programları, ağ yapılandırmalarını, yük dengeleyicileri, kullanıcı haklarını vb. de içeren geliştirme, hazırlama ve üretim ortamlarını desteklemek için önemli miktarda kapasiteye ihtiyacımız var. Önemli olan tüm bunları desteklemek için gereken çabadır. Değişiklik yapmanın ve güncellemeleri yayınlamanın birkaç yolu vardır. Örneğin GCP bağlamında tarayıcıdaki kullanıcı arayüzü konsolunu kullanabilir ve butonlara tıklayarak tüm işlemleri gerçekleştirebiliriz. Bir alternatif, bulut varlıklarıyla etkileşimde bulunmak için API çağrılarını kullanmak veya istenen işlemleri gerçekleştirmek için gcloud komut satırı yardımcı programını kullanmak olabilir. Ancak gerçekten çok sayıda farklı varlık ve altyapı öğesi olduğundan, tüm işlemleri manuel olarak gerçekleştirmek zor, hatta imkansız hale geliyor. Üstelik tüm bu manuel eylemler kontrol edilemez. Bunları yürütmeden önce incelemeye gönderemeyiz, sürüm kontrol sistemi kullanamayız ve olaya yol açan değişiklikleri hızlı bir şekilde geri alamayız. Bu tür sorunları çözmek için mühendisler, prosedürel bir tarzda hızlı bir şekilde okunması, anlaşılması, bakımı ve değiştirilmesi o kadar kolay olmadığından, önceki yöntemlerden çok daha iyi olmayan otomatik bash/shell komut dosyaları oluşturdu ve oluşturdu.
Bu makalede ve nasıl yapılır kılavuzunda IaC uygulamasıyla ilgili 2 araç kullanıyorum. Bunlar Terraform ve Ansible'dır. Bazı insanlar, işlevleri benzer olduğundan ve birbirlerinin yerine kullanılabildiğinden bunları aynı anda kullanmanın bir anlamı olmadığına inanıyor. Ancak gerçek şu ki, başlangıçta onlara tamamen farklı görevler veriliyor. Bu araçların birbirini tamamlaması gerektiği gerçeği, HashiCorp ve RedHat'ı temsil eden geliştiricilerin ortak sunumuyla doğrulandı. Kavramsal fark, Terraform'un sunucuların kendilerini yönetmeye yönelik bir sağlama aracı olmasıdır. Ansible, görevi bu sunuculara yazılım yüklemek, yapılandırmak ve yönetmek olan bir yapılandırma yönetimi aracıdır.
Bu araçların bir diğer önemli ayırt edici özelliği kodlama stilidir. Bash ve Ansible'dan farklı olarak Terraform, yürütme sonucunda elde edilmesi istenen son durumun tanımına dayanan bildirimsel bir stil kullanır. Örneğin 10 VM oluşturup değişiklikleri Terraform üzerinden uygulayacaksak 10 VM elde edeceğiz. Betiği tekrar çalıştırırsak zaten 10 VM'miz olduğu için hiçbir şey olmayacak ve Terraform bunu biliyor çünkü altyapının mevcut durumunu bir durum dosyasında saklıyor. Ancak Ansible prosedürel bir yaklaşım kullanıyor ve ondan 10 VM oluşturmasını isterseniz, ilk başlatmada Terraform'a benzer şekilde 10 VM alacağız. Ancak yeniden başlattıktan sonra zaten 20 VM'miz olacak. Önemli fark bu. Prosedürel tarzda, mevcut durumu saklamayız ve sadece gerçekleştirilmesi gereken adımların sırasını tanımlarız. Elbette çeşitli durumlarla başa çıkabiliriz, kaynakların varlığına ve mevcut duruma ilişkin birkaç kontrol ekleyebiliriz ancak bu mantığı kontrol etmek için zaman kaybetmenin ve çaba harcamanın bir anlamı yok. Ayrıca bu durum hata yapma riskini de artırır.
Yukarıdakilerin hepsini özetleyerek, Terraform ve bildirimsel gösterimin sunucuların sağlanması için daha uygun bir araç olduğu sonucuna varabiliriz. Ancak konfigürasyon yönetimi işini Ansible'a devretmek daha iyidir. Bunu bir kenara bırakarak otomasyon bağlamındaki kullanım durumlarına bakalım.
Otomasyon altyapısı için değer
Burada anlaşılması gereken tek önemli nokta, test otomasyon altyapısının tüm şirket altyapısının bir parçası olarak değerlendirilmesi gerektiğidir. Bu, tüm IaC uygulamalarının küresel olarak tüm organizasyonun kaynaklarına uygulanması gerektiği anlamına gelir. Bundan kimin sorumlu olacağı süreçlerinize bağlıdır. DevOps ekibi bu konularda daha deneyimlidir ve olup bitenin tüm resmini görürler. Bununla birlikte, QA mühendisleri bina otomasyonu sürecine ve boru hattının yapısına daha fazla dahil oluyor ve bu da onların gerekli tüm değişiklikleri ve iyileştirme fırsatlarını daha iyi görmelerine olanak tanıyor. En iyi seçenek, beklenen sonuca ulaşmak için birlikte çalışmak, bilgi ve fikir alışverişinde bulunmaktır.
Test otomasyonu ve daha önce tartıştığımız araçlar bağlamında Terraform ve Ansible kullanımına ilişkin birkaç örnek:
1. Terraform'u kullanarak VM'lerin ve kümelerin gerekli özelliklerini ve parametrelerini tanımlayın.
2. Ansible'ı kullanarak test için gerekli araçları yükleyin: docker, Selenoid, Selenium Grid ve tarayıcıların/emülatörlerin gerekli sürümlerini indirin.
3. Terraform'u kullanarak GitLab Runner'ın başlatılacağı VM'nin özelliklerini açıklayın.
4. Ansible'ı kullanarak GitLab Runner'ı ve gerekli eşlik eden araçları yükleyin, ayarları ve yapılandırmaları yapın.
Altyapının mevcut durumunun gösterimi
Keşfedilecek bağlantılar:
Benzer araçlar
Özetleyelim!
adım
Teknoloji
Tools
Otomasyon altyapısı için değer
1
Yerel koşu
Node.js, Selenyum, Appium
- Web ve mobil cihazlar için en popüler araçlar
- Birçok dili ve platformu destekler (Node.js dahil)
2
Sürüm kontrol sistemleri
Git
- Geliştirme koduyla benzer avantajlar
3
Konteynerizasyon
Docker, Selenyum ızgarası, Selenoid (Web, Android)
- Testleri paralel çalıştırma
- Yalıtılmış ortamlar
- Basit, esnek sürüm yükseltmeleri
- Kullanılmayan kaynakları dinamik olarak durdurma
- Kurulumu kolay
4
CI/CD
Gitlab CI
- Boru hattının bir kısmını test eder
- Hızlı Geri Bildirim
- Tüm şirket/ekip için görünürlük
5
Bulut platformları
Google Bulut Platformu
- Talep üzerine kaynaklar (yalnızca ihtiyaç duyulduğunda ödeme yaparız)
- Yönetimi ve güncellemesi kolay
- Tüm kaynakların görünürlüğü ve kontrolü
6
orkestrasyon
Kubernetes
Bölmelerin içinde tarayıcılar/emülatörler bulunan kaplar bağlamında:
- Ölçekleme/otomatik ölçeklendirme
- Kendi kendini iyileştirme
- Kesintisiz güncellemeler ve geri almalar
7
Kod olarak altyapı (IaC)
Terraform, Ansible
- Geliştirme altyapısıyla benzer faydalar
- Kod sürümü oluşturmanın tüm avantajları
- Değişiklik yapmak ve korumak kolaydır
- Tam otomatik
Zihin haritası diyagramları: altyapının evrimi
adım1: Yerel
adım2: VCS
3. adım: Konteynerizasyon
adım4: CI/CD
5. adım: Bulut Platformları
adım6: Düzenleme
adım7: IaC
Sırada ne var?
Yani bu makalenin sonu. Ama sonuç olarak sizinle bazı anlaşmalar yapmak istiyorum.
Senin açından
Başlangıçta da söylediğim gibi, makalenin pratik kullanıma yönelik olmasını ve edinilen bilgileri gerçek işte uygulamanıza yardımcı olmasını istiyorum. tekrar ekliyorum.
Ancak bundan sonra bile durmayın, pratik yapın, ilgili bağlantıları ve kitapları inceleyin, şirketinizde nasıl çalıştığını öğrenin, geliştirilebilecek yerleri bulun ve içinde yer alın. İyi şanlar!
Benim tarafımdan
Başlıktan bunun sadece ilk bölüm olduğunu anlayabilirsiniz. Oldukça geniş olmasına rağmen önemli konulara hala burada değinilmiyor. İkinci bölümde otomasyon altyapısına IOS bağlamında bakmayı planlıyorum. Apple'ın iOS simülatörlerini yalnızca macOS sistemlerinde çalıştırma konusundaki kısıtlamaları nedeniyle çözüm yelpazemiz daralmıştır. Örneğin, simülatörü çalıştırmak için Docker'ı veya sanal makineleri çalıştırmak için genel bulutları kullanamıyoruz. Ancak bu başka alternatifin olmadığı anlamına gelmiyor. Gelişmiş çözümler ve modern araçlarla sizi güncel tutmaya çalışacağım!
Ayrıca izlemeyle ilgili çok geniş konulardan bahsetmedim. 3. Bölümde en popüler altyapı izleme araçlarına ve hangi veri ve ölçümlerin dikkate alınması gerektiğine bakacağım.
Ve sonunda. Gelecekte test altyapısı ve popüler araçlar oluşturma konusunda bir video kursu yayınlamayı planlıyorum. Şu anda internette DevOps ile ilgili epeyce kurs ve ders var, ancak tüm materyaller test otomasyonu değil, geliştirme bağlamında sunuluyor. Bu konuda böyle bir kursun test uzmanları ve otomasyon mühendisleri topluluğu için ilginç ve değerli olup olmayacağı konusunda geri bildirimlere gerçekten ihtiyacım var. Şimdiden teşekkür ederim!
Kaynak: habr.com