CI/CD Uygulamalı: Basit Ama İşlevsel Bir Sürekli Entegrasyon İş Akışı [Bölüm 1]

CI/CD köklü bir yazılım geliştirme dogmasıdır. İnternet CI/CD hakkında konuşan makaleler ve sayfalarla doludur. Her zaman aynı CI/CD görüntüsüne sahiptirler. Eminim bahsettiğim görüntüyü biliyorsunuzdur.

Konuyla ilgili düzinelerce makale okudum ve uçtan uca CI/CD hattının uygulanmasını deneyimledim. Gerçek şu ki, bir CI/CD hattını uygulamak makaleleri okumaktan, CI/CD'nin genel resmini anlamaktan ve teoriyi kullanmaktan çok daha karmaşıktır. CI/CD üretim hattının geliştirilmesi disiplinler arası ve deneyimli ekipler gerektirir.

Bu makalede, bir Python uygulamasının minimum uygulanabilir CI işlem hattının nasıl oluşturulacağı açıklanmaktadır. Makale içeriğini diğer dillere ve gereksinimlere göre uyarlayabilirsiniz. Örnek, FastAPI ve GitHub Eylemlerini kullanır.

CI: Sürekli Entegrasyon

Mevcut sürekli entegrasyon açıklamalarına iki sentimi ekleyeyim. Sürekli entegrasyon, otomatik olarak test edilen, onaylanan ve teslim edilebilir kod değişikliklerinin proje havuzunda düzenli olarak birleştirilmesi anlamına gelir.

Bu örnek, kodun depo kalite standartlarına uygunluğunu garanti etmek amacıyla her 'Çekme İsteği' veya 'Anaya Gönder' olayında gerekli kontrolleri otomatik olarak yürütmek için GitHub Eylemlerini kullanır. Piyasada çok çeşitli CI/CD araçları koleksiyonu sunulmaktadır: Jenkins , Travis , CircleCI , GitLab, vb. İşlem hattı gereksinimlerinize en uygun olanı seçin.

Örnek iş akışı, yeni kodun pre-commit çalıştıran biçimlendirme kurallarına uyup uymadığını kontrol eder. Daha sonra Pytest'i kullanarak küçük testleri ve son olarak Helm Chart uygulamasını bir Kin D kümesine yükleyerek orta testleri gerçekleştirir.

Sürekli entegrasyon iş akışınız ekibinizin büyüklüğüne, olgunluğuna, uygulama gereksinimlerine ve dallanma stratejinize bağlı olacaktır.

Statik Kod Analizi

Kod değişikliklerini yürütmeden analiz edin. Statik analiz araçları, kodunuzun biçimlendirme kurallarına uyup uymadığını, kullanımdan kaldırılmış veya bozulmuş bağımlılıklar kullanmadığını, okunabilir ve yeterince basit olup olmadığını kontrol eder. Ayrıca programlama diline bağlı olarak anti-örüntülerin ve hataların kodlanmasını da önerirler.

Pre-commit'in nasıl kurulacağını, yapılandırılacağını ve çalıştırılacağını açıklayacağız. Pre-commit'i Sonar veya Synk gibi diğer analiz araçlarıyla birleştirebilirsiniz.

Ön taahhüt

Pre-commit Python'da yazılmış bir araçtır. Bunu deponuzda yapılandırmak, bir YAML dosyası oluşturmak ve her işlemden önce çalıştırmak istediğiniz sürümlendirilmiş kancaları eklemek kadar basittir. Pre-commit, kancaların gerektirdiği bağımlılıkları otomatik olarak yönetir ve bulunan hataları otomatik olarak düzeltir. Birden fazla dosya türünü destekler: JSON, YAML, tf, py, ts, vb.

Kod kontrollerinizi göndermeden önce yerel olarak çalıştırarak altyapı maliyetlerinden tasarruf edin. Gönderilen kodun formatını kontrol etmek için CI'nızda Pre-commit'i çalıştırabilirsiniz.

Ön işleme aracını yükleyin, yapılandırın ve çalıştırın:

 repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace

 $ pip install pre-commit $ pre-commit install $ pre-commit run --all-files

Ölçek

Birim, Entegrasyon ve Uçtan Uca test tanımları ve kapsamı bazen dağınıktır. Sürekli Entegrasyon açıklamasında yaptığım gibi, iki kuruşumu Google'daki Yazılım Mühendisliği test türlerine ekleyeceğim:

• Küçük : Hızlı testler. Küçük kod parçalarını test edin. Test çiftlerini veya sahte ortamları (örn. SQLite) kullanın. Herhangi bir eser inşa etmek gerekli değildir. Süre: ~ 60 saniye.

• Orta : Birden fazla kod parçası arasındaki etkileşimi test edin. Yapıtların oluşturulmasını, üçüncü taraf yapıtların (örn. veritabanı ) kullanılması ve yerel ana bilgisayar ağına bağlanmayı içerebilirler. Sahte ortamların (örn. docker-compose, Kind, Minikube vb.) veya harici hizmetlerin (örn. Azure Blob Storage veya AWS S3) kullanımı. Süre: ~ 300 saniye.

• Büyük : Üretim benzeri ortamlar kullanırlar (örn. Performans Testi). Süre: +900 saniye.

  
  

Sürekli entegrasyon hattınızda orta/büyük testlerin yapılıp yapılmaması gereksinimlerinize bağlıdır.

Küçük

Örnek, testleri çalıştırmak için Pytest'i ve ortamı taklit etmek için FastAPI test istemcisini kullanır. Sırlar yok; programlama dili test aracınız, uygulamanızı test etmek için gerekli tüm bağımlılıkları size sağlamalıdır.

Ek olarak, minimum test kapsamı kontrolü ekleyebilir ve bunu sonuçlarınızın bir parçası olarak yükleyebilirsiniz. Test kapsamı zor bir ölçümdür. Test kapsamının yüksek olması, dolaylı olarak iyi test edilmiş bir koda sahip olmak anlamına gelmez, ancak %50, test edilmiş %0 koddan daha fazladır.

Orta

Kin D, yerel geliştirme veya CI için kullanılan, docker-in-docker hafif bir Kubernetes kümesidir. Kind'i bir test ortamı oluşturmak ve testleri buna göre yürütmek için kullanırız:

1. Tür kümesini oluşturma
2. Docker Görüntüsünü Oluşturun
3. Docker Görüntüsünü Kind'e Yükleyin
4. MetalLB'yi kurun ve gerekli CDR'leri uygulayın
5. Ingress-Nginx'i yükleyin
6. Dümen Tablonuzu yükleyin
7. İşletim sistemi ana makinenizi kurun

Docker Görüntülerini Yükle

Kind, resminizi bir kayıt defterinden indirilemediği için indiremez. Kind, görselin kullanılmadan önce yüklenmesini gerektirir.

MetalLB

MetalLB, yalın donanım Kubernetes yük dengeleyicisidir. MetalLB web sayfasında bir yük dengeleyicinin neden gerekli olduğu hakkında daha fazla bilgi edinin.

Dümen Grafiği kullanılarak kurulduktan sonra gerekli CRD'leri oluşturabiliriz:

 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement --- apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: kind-address-pool spec: addresses: - "172.26.255.0/24"

Docker, Kind kümesi için bir alt ağ oluşturur (örn. 172.26.0.0/16). Atanan IP adresi aralığını öğrenmek ve adresi IPAddressPool kaynağı için bir değer olarak kullanmak için Kind ağ arayüzünü inceleyin. MetalLB konfigürasyonu hakkında daha fazla bilgiyi KinD web sayfasında bulabilirsiniz.

Uygulamayı Açığa Çıkarın

Ingress-Nginx Helm Chart'ı yükleyin. Ardından, bir Ingress nesnesi tanımlayarak uygulamanızı Helm Chart'ı yükleyin. ingressClassName özelliğini nginx olarak ayarlayın ve bir ana bilgisayar tanımlayın (örn. api.local). Son olarak, aşağıdaki satırı eklemek için /etc/host dosyasını değiştirin:

 192.168.1.10 api.local

Aynı adrese işaret ederek istediğiniz kadar host tanımlayabilirsiniz. Gerisini Nginx halledecek.

Teslimat

Gerekli yapıtları teslim etmeden önce iş akışı, astarlama ve test adımlarını yürütür.

Yapıların sürümlerini yönetmek için Commitizen'i kullanıyoruz. Commtizen, yapı sürümünü otomatik olarak günceller ve değişiklikleri aktarır. Yapılandırılmış etiket biçimiyle yeni bir git etiketi oluşturur. Commtizen'i Changelog'unuzu en son değişikliklerle güncelleyecek şekilde de yapılandırabilirsiniz.

 [tool.commitizen] tag_format = "v$major.$minor.$patch" version_scheme = "semver" version_provider = "pep621" major_version_zero = true update_changelog_on_bump = true version_files = [ "charts/ci-example/Chart.yaml:version", "charts/ci-example/Chart.yaml:appVersion" ]

İş akışı, Docker Image ve Helm Chart etiketini ayarlamak için Commitizen çıktı sürümünü kullanır.

Sonuçlar

Bu makale basit ama işlevsel bir sürekli entegrasyon iş akışının taslağını çizmektedir. Diğer programlama dillerinde çalışması veya gereksinimlerinize uyması için değişiklikler yapılması gerekebilir, ancak bazı adımların kolayca dışa aktarılabilmesi ve olduğu gibi çalışması gerekir.

CI/CD Uygulamalı: Sürekli Dağıtım [Bölüm 2] Çok Yakında…