Devops, hem geliştirme hem de operasyon faaliyetlerini kapsayan genel görünümü alır ve en etkili şekilde etkileşimde bulunmak için bunların koreografisini yapar. Kavramsal ideal bu, ancak teknik açıdan ideal devops kurulumunu tanımlayabilir miyiz?

Cevap hayır, çünkü iki kişilik bir girişimin talepleri, bakımı ve beslenmesiyle ilgilenen yüzlerce insanın yer aldığı bir mikro hizmet projesine başlayan çok uluslu bir şirketin taleplerinden kökten farklı.

Ama biz Yapabilmek Gerektiğinde artan karmaşıklığı emmek için esneyen idealleştirilmiş bir geliştirme akışını ve CI/CD, Docker ve bulut bilişim gibi teknolojilerin bu akışa nasıl uyduğunu tanımlayın.

Geliştirme: “İç döngü”

Diyelim ki bir geliştiricisiniz. Doğal olarak yazılımda değişiklikler yapıyorsunuz ve değişikliklerinizden memnun olduğunuzda bunları sürüm kontrolüne alıyorsunuz. Sürüm kontrolü, yazılım geliştirmenin “iç döngüsü” ile geliştiricilerin “dış döngüsü” arasındaki bağlantı noktasıdır.

Geliştirici taahhüdü, bir geliştirme şubesine, bir özellik şubesine veya (resmi olmayan bir ortamda) doğrudan ana bölüme gidebilir, ancak ideal olarak, birim testlerinin otomatik olarak çalıştırılması olacaktır. Bu, çeşitli şekillerde olabilir – ön taahhüt kancaları, taahhüt kancaları aracılığıyla, seçenekler sonsuzdur. Ancak sonuçta birim testleri geçmediği sürece kod değişikliği şubeye kabul edilmeyecektir.

Otomatik test

Artık kod değişikliği kabul edildiğine göre, yapılması gereken bir sonraki meta-şey “entegrasyon testi” başlığına giriyor ve bu, sürekli entegrasyondaki temel adımdır; yani, kod sürekli olarak daha büyük sisteme (ne olursa olsun) entegre edilir ve çalışan bir ortamda otomatik ve manuel test için dağıtılır.

Otomatik test söz konusu olduğunda gökyüzü sınırdır. Selenium tarzı otomatikleştirilmiş UI testinden gelişmiş yük testi takımlarına kadar, yazılımınızı güçlendirmek için mevcut her türlü modern otomatik araçla her şey masada. Çoğu zaman, bir tür otomatik duman testi, teste terfi eden yazılımın nominal olarak çalışmasını sağlar.

Testin mantrası, Sorunları olabildiğince erken yakalayın.

Manuel doğrulama testleri

Yazılım, birimi ve otomatik entegrasyon testi engellerini ortadan kaldırdığına göre, manuel test için hazır olabilir. Genellikle manuel test, belirli bir dizi özellik ve düzeltmeyi yakalayan belirli bir etikete karşı yapılır. Bu, değişiklikleri üretime taşıma konusunda ciddileşen kuruluş (bir kişi veya 20 kişi olabilir).

Bu, yazılımın (tercihen otomatik olarak) üretimi taklit eden ve QA’nın işleri bozmak için elinden gelenin en iyisini yapacağı, yazılımla manuel olarak etkileşime izin veren bir ayara dağıtıldığı anlamına gelir. Sorunları bulduktan sonra, düzeltmeler birleştirilebilir.

QA’daki iyi insanlar tatmin olduğunda, gelecek vaat eden paket UA’ya veya kullanıcı kabul testine terfi edebilir. Bu çeşitli şekillerde olabilir, ancak sonuçta daha fazla insan (iş analistleri ve diğer paydaşlar) çalışan yazılımdan haberdar olur. İmzaladıktan sonra, yazılım üretime hazırdır.

Üretimdeki değişiklikleri izleme

Üretimdeki değişikliklerin ne kadar büyük olduğuna bağlı olarak, bu ortamda gerçekleşen daha fazla doğrulama etkinliği vardır, ancak yeni bir yön de geçerlidir: izleme. İzleme ve günlük kaydı, genel sistemin nasıl performans gösterdiğine ilişkin sekmeleri tutmak için gereklidir. Bu, bulut çağında büyük gelişmeler görülen başka bir alandır. Çok sayıda günlük kaydı ve izleme aracı mevcuttur.

Mikro hizmetler alanında, micorservice öğeleri aşamalar halinde dağıtılabileceğinden, ağ trafiğinin diğer bileşenlerle amaçlandığı gibi etkileşime girdiklerini doğrulamak için aşamalı olarak güncellenen düğümlere yönlendirildiğinden, üretime dağıtım bazen daha karmaşık bir meseledir.

Devops’taki roller

Bu süreçleri değerlendirmenin başka bir yolu da insanların bu süreçlerde oynadıkları rollerdir. Rollerle, insanların giydiği şapkaları kastediyorum, mutlaka iş unvanlarını değil. En üst düzeyde, üç rol olduğunu söyleyebilirsiniz: kodu değiştiren kişiler, işlerin düzgün çalıştığını doğrulayan kişiler ve çalışan sistemleri yöneten kişiler.

Onlara geliştiriciler, testçiler ve yöneticiler diyebiliriz.

Daha fazla ayrıntıya yaklaştıkça, elbette daha fazla çeşitlilik var. Örneğin, yeni kod değişikliklerini test eden bir QA mühendisi, bir UA sunucusundaki gereksinimleri doğrulayan bir iş analistinden oldukça farklıdır; her ikisi de, üretim sistemlerinin belirtilen parametreler dahilinde çalıştığını doğrulamak için monitörleri yapılandıran bir devops mühendisinden farklıdır. Ancak bu faaliyetlerin, işlerin gerektiği gibi çalıştığını doğrulama geniş başlığı altına girdiğini söyleyebiliriz.

Bu şapka takanların işlerinde kullandıkları bazı özel araçlar hakkında konuşmak için bu bakış açısını kullanalım.

Kapsayıcılar: Geliştirme operasyonları menteşesi

Belki de en çok kesişen teknoloji, pratikte Docker anlamına gelen konteynerleştirmedir. Bunun nedeni, Docker’ın bir geliştiricinin yazılımını, çalışma zamanı ihtiyaçlarını tanımlayan konuşlandırılabilir parçalar halinde bileşenlerine ayırmasına izin vermesidir. Bu, geliştiricilerin kapsayıcıyı hedefleyebileceği ve yöneticilerin kapsayıcıyı sistemler arasında ortak payda olarak kullanabileceği anlamına gelir.

Konteyner düzeyinde konuşlandırılabilir birim, en yüksek hacimli ve zorlu gereksinimleri bile desteklemek için yeterlidir. Kubernetes, en popüler kapsayıcı küme yönetim sistemi haline geldi ve basit bir teknoloji parçası olmasa da, birden çok bölgede büyük kümeleri yönetme ve etkileşimli hizmetler ile yetenekleri etkileyici.

Konteynerler ve geliştirme

Bununla birlikte, kapsayıcılaştırma, geliştiricinin “iç döngüsü” için kolay değildir. Bunun nedeni, kapsayıcıların kod, derleme ve test döngüsüne ekstra karmaşıklık getirmesidir. Bu nedenle, geliştiricilerin kodlarını kapsayıcı olmayan yerel ortamlarına karşı çalıştırdıkları “patlamış” bir geliştirme ortamı kullanmaları hala daha yaygındır.

Birim testi, kod kalitesinde geliştiricinin ön saf savunması olmaya devam ediyor. Yine de Docker, örneğin MongoDB veya PostgreSQL gibi bir veri deposunun standartlaştırılmış bir sürümünü paketleyerek geliştiricilerin kodlama sırasında kullanması için kolaylıkla döndürülmesine olanak tanıyarak geliştirici için bazı yönleri daha basit hale getirebilir.

Kapsayıcılar ve test verileri

Aynı şekilde, geliştirme ortamları, test verileriyle veritabanlarını döndürmek için Docker ve Docker Compose kullanarak sıklıkla fayda sağlayabilir.

Docker, devops ortamını birleştirmede kilit rol oynasa ve geliştiricilere belirli avantajlar sunsa da, gerçek kodlama görevlerine geldiğinde bazı uyumsuzluklar vardır.

CI/CD ardışık düzen araçları

Şimdi çeşitli öğeleri bir devops ardışık düzenine bağlamak için kullanılabilecek araçları ele alalım. Çok var.

kendi koşun

En eski CI sunucusu, çok popüler ve yetenekli olmaya devam eden Jenkins’dir. Başlıca kusuru zayıf dokümantasyondur. Jenkins ve eklentiler evreni ile hemen hemen her şey yapılabilir, ancak bu genellikle kendi başınıza çözebileceğiniz bir deneyimdir.

Jenkins, genellikle bir bulut sanal makinesinde kendiniz kurduğunuz ve çalıştırdığınız bir sunucudur. Ardından, GitHub’dan veya diğer sürüm kontrol sistemlerinden çekerek, derlemeler ve testler yürüterek, bir Docker kayıt defteriyle etkileşimde bulunarak, hedef ortamlara dağıtarak vb. şeylerin düzenleyicisi olarak hareket eder. Daha yeni çözümler, birçok SaaS teklifini içerir. Birkaç tane düşünelim.

SaaS seçenekleri

GitLab CI/CD ve CircleCI, fikir paylaşımı kazanmış iki yeni sürekli entegrasyon teklifidir, ancak devops sorunlarını uygun ve etkili bir şekilde çözmeyi ümit eden yeni girenleri çeken sıcak bir alanda tek rakip olmaktan uzaktırlar. Sevkiyat, aynı zamanda popülaritesi artan, yerleşik satıcı JFrog’dan daha yeni bir seçenektir.

Test araçları

Test için Selenium, kendi yüklediğiniz ve yapılandırdığınız ücretsiz açık kaynaklı yazılım olması bakımından Jenkins’in doğal sonucudur. Bu, Appium veya çeşitli bulut sağlayıcılarından bazı SaaS tekliflerinin aksine.

CI/CD alanı gibi, test etme çok aktif bir pazardır.

Altyapı araçları

AWS CloudFormation, Ansible, Chef, Puppet ve Terraform gibi kod olarak altyapı araçları, Docker ve Kubernetes’i barındırmak için kullanılan temel sistemleri kontrol etme yeteneği sunar. Bu araçları hak etmek için belirli bir sistem karmaşıklığı düzeyi gereklidir, ancak bu eşiğe ulaşıldığında, bunlar devops süreci için kesinlikle gerekli hale gelir.

Yapabileceğiniz her şeyi otomatikleştirin

Genel olarak, devops’un sorumluluğunun, geliştirme ve operasyonları uyumlu, işbirlikçi bir sistemde birleştirmek olduğunu söyleyebiliriz. İdeal olan, mümkün olduğu kadar otomatikleştirmek ve insan müdahalesinin istendiği her yerde, gerekli görevlerin tekrarlanabilir, tek tıklamayla yürütülmesini sağlamaktır.

Her proje ve organizasyon devam eden bir çalışmadır. Yazılımın doğası göz önüne alındığında, değişim her zaman kale direğini hareket ettirmeyi içerir. Bununla birlikte, büyük resmin ve ilgili araçların iyi anlaşılması, bu değişiklik ve tüm karmaşıklığı ile başa çıkmayı planlamamızı sağlar.

Telif Hakkı © 2021 IDG Communications, Inc.



#Devops #idealini #aramak #için