DevOps İşlem Hattı nedir? Nasıl İnşa Edilir

Günümüzde insanlar en son yenilikleri içeren favori uygulamalarını her zamankinden daha hızlı görmeyi bekliyor. Geliştiricilerin yeni yazılım ürünleri geliştirmek ve yayınlamak için yıllar harcadığı günler çoktan geride kaldı.

Bu nedenle, her yazılım geliştirme şirketinin müşteri taleplerini ve gereksinimlerini karşılayabilmek için etkili bir DevOps hattına ihtiyacı vardır.

Bu makalede DevOps işlem hattının temel kavramları, işlem hatlarının DevOps ortamlarında nasıl çalıştığı ele alınmakta ve kodun üretime dağıtılmadan önce geçmesi gereken aşamalar açıklanmaktadır.

DevOps İşlem Hattı nedir?

DevOps hattı, geliştirme (Dev) ve operasyon (Ops) ekiplerinin yazılımı daha hızlı ve daha kolay oluşturmak, test etmek ve dağıtmak için uyguladığı bir dizi uygulamadır. Bir boru hattının temel amaçlarından biri, yazılım geliştirme sürecini düzenli ve odaklı tutmaktır.

Ancak "boru hattı" terimi biraz yanıltıcı olabilir. Yazılım geliştirme sürekli bir döngü olduğundan, bir otomobil fabrikasındaki montaj hattı daha uygun bir benzetme olabilir.

Üretici, otomobili halka arz etmeden önce, otomobilin çok sayıda montaj aşamasından, testlerden ve kalite kontrolünden geçmesi gerekiyor. Müşterilerin ilgisini çekebilmek için işçilerin şasiyi inşa etmesi, motoru, tekerlekleri, kapıları, elektronik aksamı ve son boya işini eklemesi gerekiyor.

DevOps işlem hatları benzer şekilde çalışır.

Bir uygulamayı veya yeni bir özelliği kullanıcılara sunmadan önce öncelikle kodu yazmanız gerekir. Ardından uygulamanın çökmesine neden olabilecek önemli hatalara yol açmayacağından emin olun. Böyle bir senaryodan kaçınmak, herhangi bir hatayı, yazım hatasını veya hatayı tespit etmek için çeşitli testler yapmayı içerir. Son olarak, her şey amaçlandığı gibi çalışmaya başladıktan sonra kodu kullanıcılara yayınlayabilirsiniz.

Bu basitleştirilmiş açıklamadan DevOps işlem hattının oluşturma, test etme ve dağıtma aşamalarından oluştuğu sonucuna varabilirsiniz.

DevOps Pipeline'ın Bileşenleri

Kodun bir aşamadan diğerine sorunsuz bir şekilde geçmesini sağlamak için çeşitli DevOps stratejilerinin ve uygulamalarının uygulanması gerekir. Bunların arasında en önemlileri sürekli entegrasyon ve sürekli dağıtım (CI/CD)'dir.

Sürekli Entegrasyon

Sürekli entegrasyon (CI), birden fazla geliştiricinin küçük kod parçalarını mümkün olduğunca sık bir şekilde paylaşılan bir kod deposuna entegre etme yöntemidir. Bir CI stratejisiyle, diğer ekip üyelerinin kodlarına katkıda bulunmasını beklemek zorunda kalmadan, kodu hatalara karşı otomatik olarak test edebilirsiniz.

CI'nın en önemli faydalarından biri, büyük ekiplerin entegrasyon cehennemi olarak bilinen durumu engellemesine yardımcı olmasıdır.

Yazılım geliştirmenin ilk günlerinde geliştiriciler kodlarını göndermek için uzun süre beklemek zorunda kalıyorlardı. Bu gecikme, kod entegrasyonu çakışmaları ve hatalı kod dağıtımı riskini önemli ölçüde artırdı. Eski yöntemlerin aksine CI, geliştiricileri kodlarını günlük olarak göndermeye teşvik ediyor. Sonuç olarak hataları daha hızlı yakalayabilir ve sonuçta bunları düzeltmek için daha az zaman harcayabilirler.

CI'nın kalbinde bir merkezi kaynak kontrol sistemi bulunur. Birincil amacı ekiplerin kodlarını düzenlemelerine, değişiklikleri izlemelerine ve otomatik testleri etkinleştirmelerine yardımcı olmaktır.

Tipik bir CI kurulumunda, bir geliştirici paylaşılan kod deposuna yeni kod gönderdiğinde, yeni ve mevcut kodu bir yapı halinde derlemek için otomasyon devreye girer. Derleme süreci başarısız olursa geliştiriciler, hangi kod satırlarının yeniden işlenmesi gerektiğini bildiren bir uyarı alır.

İşlem hattından yalnızca kaliteli kodun geçtiğinden emin olmak çok önemlidir. Bu nedenle, birisi paylaşılan havuza her yeni kod gönderdiğinde tüm süreç tekrarlanır.

Sürekli Teslimat

Sürekli teslimat (CD), CI'nın bir uzantısıdır. Geliştiricilerin kodu üretime artımlı parçalar halinde yayınlamasını teşvik ederek sürüm sürecini hızlandırmayı içerir.

CI aşamasını geçtikten sonra kod derlemesi bir bekleme alanına taşınır. İşlem hattının bu noktasında, yapıyı üretime mi aktaracağınıza yoksa daha fazla değerlendirme için bekletip bekletmeyeceğinize karar vermek size kalmıştır.

Tipik bir DevOps senaryosunda, geliştiriciler öncelikle kodlarının nasıl davrandığını değerlendirmek için kodlarını üretim benzeri bir ortama aktarır. Bununla birlikte, yeni yapı hemen yayına alınabilir ve geliştiriciler onu istedikleri zaman bir düğmeye basarak dağıtabilirler.

Sürekli teslimden tam anlamıyla yararlanmak için kod güncellemelerini mümkün olduğunca sık dağıtın. Yayınlanma sıklığı iş akışına bağlıdır ancak genellikle günlük, haftalık veya aylıktır. Kodu daha küçük parçalar halinde yayınlamak, tüm değişiklikleri aynı anda yayınlamakla karşılaştırıldığında sorunu gidermek çok daha kolaydır. Sonuç olarak, darboğazlardan ve birleştirme çatışmalarından kaçınır, böylece istikrarlı, sürekli bir entegrasyon hattı akışını sürdürürsünüz.

Sürekli Dağıtım

Sürekli teslimat ve sürekli dağıtım birçok açıdan benzerdir ancak ikisi arasında kritik farklar vardır.

Sürekli dağıtım, geliştirme ekiplerinin yazılımı, özellikleri ve kod güncellemelerini manuel olarak dağıtmasına olanak tanırken, sürekli dağıtım tamamen tüm yayın döngüsünün otomatikleştirilmesiyle ilgilidir.

Sürekli dağıtım aşamasında kod güncellemeleri herhangi bir manuel müdahaleye gerek kalmadan son kullanıcıya otomatik olarak yayınlanır. Ancak otomatik sürüm stratejisi uygulamak tehlikeli olabilir. Süreç boyunca tespit edilen tüm hataların azaltılması başarısız olursa, hatalı kod üretime dağıtılacaktır. En kötü senaryoda bu durum uygulamanın bozulmasına veya kullanıcıların kesinti yaşamasına neden olabilir.

Otomatik dağıtımlar yalnızca küçük kod güncellemeleri yayınlanırken kullanılmalıdır. Bir şeyler ters giderse uygulamanın arızalanmasına neden olmadan değişiklikleri geri alabilirsiniz.

Sürekli dağıtımın tüm potansiyelinden yararlanmak, yeni kodun gerçekten hatasız olmasını ve üretime hemen dağıtılmaya hazır olmasını sağlayan sağlam test çerçevelerine sahip olmayı gerektirir.

Sürekli Test

Sürekli test, sorunları üretim ortamına ulaşmadan önce tespit etmek için geliştirme sürecinin her aşamasında testleri mümkün olduğunca sık çalıştırma uygulamasıdır. Sürekli bir test stratejisinin uygulanması, teslimat hattındaki belirli sürüm adaylarının iş risklerinin hızlı bir şekilde değerlendirilmesine olanak tanır.

Testin kapsamı hem fonksiyonel hem de fonksiyonel olmayan testleri kapsamalıdır. Bu, bir uygulama ve sunucu altyapısının güvenlik ve performans yönlerini ele alan çalıştırma ünitesini, sistemi, entegrasyonu ve testleri içerir.

Sürekli test, risk değerlendirmesini ve iç politikalara uyumu içeren daha geniş bir kalite kontrol anlayışını kapsar.

Sürekli Operasyonlar

Kapsamlı bir sürekli operasyon stratejisine sahip olmak, uygulamaların ve ortamların maksimum düzeyde kullanılabilirliğinin korunmasına yardımcı olur. Amaç, kullanıcıların sürekli olarak yayınlanan kod güncellemeleri, hata düzeltmeleri ve yamalardan habersiz olmasıdır. Sürekli operasyon stratejisi, kod sürümü sırasında kesinti ve kullanılabilirlik sorunlarının önlenmesine yardımcı olabilir.

Sürekli operasyonların avantajlarından yararlanmak için sunucuların, veritabanlarının, kapsayıcıların, ağların, hizmetlerin ve uygulamaların sürekli performans takibini gerçekleştirebilecek sağlam bir otomasyon ve orkestrasyon mimarisine sahip olmanız gerekir.

DevOps Pipeline'ın Aşamaları

Boru hattını nasıl yapılandırmanız gerektiğine ilişkin sabit kurallar yoktur. DevOps ekipleri, belirli iş akışlarına bağlı olarak belirli aşamaları ekler ve kaldırır. Yine de neredeyse her ardışık düzen dört temel aşamadan oluşur: geliştirme, oluşturma, test ve dağıt.

Bu kurulum, profesyonel DevOps ortamlarında da oldukça yaygın olduğundan iki aşama daha ( planlama ve izleme) eklenerek genişletilebilir.

Planlama

Planlama aşaması, geliştiriciler kodlamaya başlamadan önce tüm iş akışının planlanmasını içerir. Bu aşamada ürün yöneticileri ve proje yöneticileri önemli bir rol oynamaktadır. Süreç boyunca tüm ekibe rehberlik edecek bir geliştirme yol haritası oluşturmak onların görevidir.

Kullanıcılardan ve paydaşlardan geri bildirim ve ilgili bilgiler toplandıktan sonra iş, bir görev listesine bölünür. Ekipler, projeyi daha küçük, yönetilebilir parçalara bölerek sonuçları daha hızlı teslim edebilir, sorunları yerinde çözebilir ve ani değişikliklere daha kolay uyum sağlayabilir.

DevOps ortamında ekipler, bireysel ekip üyelerinin kendilerine atanan görevler üzerinde çalıştığı daha kısa bir süre (genellikle iki hafta uzunluğunda) olan sprintlerde çalışır.

Geliştir

Geliştirme aşamasında geliştiriciler kodlamaya başlar. Programlama diline bağlı olarak geliştiriciler, maksimum üretkenliğe ulaşmak için yerel makinelerine uygun IDE'leri (Python IDE'ler, Java IDE'ler vb.), kod düzenleyicileri ve diğer teknolojileri yüklerler.

Çoğu durumda, geliştiricilerin tek tip bir kodlama modeli sağlamak için belirli kodlama stillerini ve standartlarını takip etmesi gerekir. Bu, herhangi bir ekip üyesinin kodu okumasını ve anlamasını kolaylaştırır.

Geliştiriciler kodlarını göndermeye hazır olduklarında, paylaşılan kaynak kod deposuna bir çekme isteğinde bulunurlar. Ekip üyeleri daha sonra yeni gönderilen kodu manuel olarak inceleyebilir ve ilk çekme isteğini onaylayarak ana dalla birleştirebilir.

Oluştur

DevOps işlem hattının oluşturma aşaması çok önemlidir çünkü geliştiricilerin koddaki hataları, işlem hattında ilerlemeden ve büyük bir felakete neden olmadan önce tespit etmelerine olanak tanır.

Yeni yazılan kod paylaşılan depoyla birleştirildikten sonra geliştiriciler bir dizi otomatik test yürütür. Tipik bir senaryoda, çekme isteği, kodu bir yapıya (konuşlandırılabilir bir pakete veya yürütülebilir bir dosyaya) derleyen otomatik bir işlemi başlatır.

Bazı programlama dillerinin derlenmesine gerek olmadığını unutmayın. Örneğin, Java ve C ile yazılan uygulamaların çalışması için derlenmesi gerekirken, PHP ve Python ile yazılan uygulamaların çalışması gerekir. yapma.

Kodda bir sorun varsa derleme başarısız olur ve geliştiriciye sorunlar bildirilir. Böyle bir durumda ilk çekme isteği de başarısız olur.

Geliştiriciler, yalnızca hatasız kodun işlem hattında devam etmesini sağlamak için paylaşılan depoya her gönderimde bu işlemi tekrarlar.

Test

Derleme başarılı olursa test aşamasına geçilir. Burada geliştiriciler, kodun bütünlüğünü daha da doğrulamak için manuel ve otomatik testler yürütür.

Çoğu durumda, Kullanıcı Kabul Testi gerçekleştirilir. İnsanlar, kodu üretime göndermeden önce ek değişiklikler gerekip gerekmediğini belirlemek için son kullanıcı olarak uygulamayla etkileşime girer. Bu aşamada güvenlik, performans ve yük testinin yapılması da yaygındır.

Dağıt

Derleme Dağıtım aşamasına ulaştığında yazılım üretime aktarılmaya hazırdır. Kodun yalnızca küçük değişikliklere ihtiyacı varsa otomatik dağıtım yöntemi kullanılır. Ancak uygulama büyük bir revizyondan geçmişse, yeni eklenen kodun nasıl davranacağını izlemek için yapı ilk olarak üretim benzeri bir ortama dağıtılır.

Önemli güncellemeler yayınlanırken mavi-yeşil dağıtım stratejisinin uygulanması da yaygındır.

Mavi-yeşil dağıtım, bir ortamın geçerli uygulamayı barındırdığı, diğer ortamın ise güncellenmiş sürümü barındırdığı iki özdeş üretim ortamına sahip olmak anlamına gelir. Değişiklikleri son kullanıcıya yayınlamak için geliştiricilerin tüm istekleri uygun sunuculara iletmesi yeterlidir. Sorun olması durumunda geliştiriciler hizmet kesintisine neden olmadan önceki üretim ortamına kolayca dönebilirler.

İzle

DevOps hattının bu son aşamasında operasyon ekipleri, her şeyin sorunsuz çalıştığından emin olmak için altyapıyı, sistemleri ve uygulamaları sürekli olarak izleyerek yoğun bir şekilde çalışıyor. Performans sorunlarını ortaya çıkarmak için günlüklerden, analizlerden ve izleme sistemlerinden değerli verilerin yanı sıra kullanıcılardan gelen geri bildirimleri toplarlar.

İzleme aşamasında toplanan geri bildirimler, DevOps hattının genel verimliliğini artırmak için kullanılır. Potansiyel darboğazları veya üretkenliği engelleyebilecek diğer sorunları ortadan kaldırmak için her sürüm döngüsünden sonra işlem hattında ince ayar yapmak iyi bir uygulamadır.

DevOps İşlem Hattı Nasıl Oluşturulur

Artık DevOps işlem hattının ne olduğunu ve nasıl çalıştığını daha iyi anladığınıza göre, CI/CD işlem hattı oluştururken gerekli adımları inceleyelim.

Kaynak Kontrol Ortamı Oluşturma

Siz ve ekibiniz kodu oluşturmaya ve dağıtmaya başlamadan önce kaynak kodunu nerede saklayacağınıza karar verin. GitHub, açık ara en popüler kod barındırma web sitesidir. GitLab ve BitBucket güçlü alternatiflerdir.

GitHub'ı kullanmaya başlamak için ücretsiz bir hesap açın ve paylaşılan bir depo oluşturun. Kodu GitHub'a aktarmak için önce Git'i yerel makineye yükleyin. Kodu yazmayı bitirdikten sonra onu paylaşılan kaynak kodu deposuna gönderin. Aynı proje üzerinde birden fazla geliştirici çalışıyorsa, diğer ekip üyeleri genellikle yeni kodu ana dalla birleştirmeden önce manuel olarak inceler.

Derleme Sunucusu Kurma

Kod GitHub'a yüklendikten sonraki adım onu test etmektir. Koda yönelik testler çalıştırmak, hataların, hataların veya yazım hatalarının kullanıcılara dağıtılmasını önlemeye yardımcı olur.

Kodun üretime hazır olup olmadığı çok sayıda testle belirlenebilir. Hangi analizlerin çalıştırılacağına karar vermek, projenin kapsamına ve uygulamayı çalıştırmak için kullanılan programlama dillerine bağlıdır.

Yapı oluşturmaya yönelik en popüler çözümlerden ikisi Jenkins ve Travis-CI'dir. Jenkins tamamen ücretsiz ve açık kaynaktır; Travis-CI ise yine ücretsiz ancak yalnızca açık kaynaklı projeler için barındırılan bir çözümdür.

Testleri çalıştırmaya başlamak için Jenkins'i bir sunucuya yükleyin ve GitHub deposuna bağlayın. Daha sonra Jenkins'i, paylaşılan depodaki kodda her değişiklik yapıldığında çalışacak şekilde yapılandırabilirsiniz. Kodu derler ve bir yapı oluşturur. Derleme süreci sırasında Jenkins herhangi bir sorunla karşılaşırsa otomatik olarak uyarı verir.

Otomatik Testleri Çalıştırın

Çok sayıda test vardır ancak en yaygın olanları birim testleri, entegrasyon testleri ve işlevsel testler'dir.

Geliştirme ortamına bağlı olarak, otomatik testleri birbiri ardına çalışacak şekilde düzenlemek en iyisidir. Genellikle en kısa testleri test sürecinin başında çalıştırmak istersiniz.

Örneğin, tamamlanması daha fazla zaman aldığı için birim testlerini işlevsel testlerden önce çalıştırırsınız. Yapı test aşamasını başarılı bir şekilde geçerse, daha fazla değerlendirme için kodu üretime veya üretim benzeri bir ortama dağıtabilirsiniz.

Üretime Dağıt

Kodu üretime dağıtmadan önce ilk olarak sunucu altyapısını kurun. Örneğin, bir web uygulamasını dağıtmak için Apache gibi bir web sunucusu yüklemeniz gerekir. Uygulamanın bulutta çalışacağını varsayarsak büyük olasılıkla onu bir sanal makineye dağıtacaksınız.

Fiziksel donanımın tam işleme potansiyelini gerektiren uygulamaları özel sunuculara veya çıplak donanım bulut sunucularına dağıtabilirsiniz.

Bir uygulamayı dağıtmanın iki yolu vardır: manuel veya otomatik. İlk başta, dağıtım süreci hakkında fikir sahibi olmak için kodu manuel olarak dağıtmak en iyisidir. Daha sonra otomasyon süreci hızlandırabilir, ancak yalnızca kendinize güveniyorsanız kötü kodun üretime girmesini engelleyecek engeller vardır.

Kodu üretime bırakmak basit bir işlemdir. Dağıtımın en kolay yolu, yapı sunucusunu, kodu otomatik olarak üretime bırakan bir komut dosyasını yürütecek şekilde yapılandırmaktır.

Kapanışta

Artık Devops işlem hattının ne olduğunu ve yazılım geliştirme yaşam döngünüzü hızlandırmaya nasıl yardımcı olabileceğini anlıyorsunuz.

Ancak bu buzdağının sadece görünen kısmı.

DevOps hattı geniş bir konudur ve her kuruluşun kendi iş akışlarına bunu entegre etme yöntemi olacaktır. Nihai hedef, otomasyonun avantajlarından yararlanan ve yüksek kaliteli ürünlerin daha hızlı ve daha kolay sunulmasına yardımcı olmak için sürekli iyileştirmelere olanak tanıyan tekrarlanabilir bir sistem oluşturmaktır.