Continuous Integration (CI)

Sürekli tümleştirme (CI), her geliştiricinin değişikliklerini en az günde bir kez sık sık paylaşılan bir ana dala birleştirme ve her değişikliği otomatik olarak derleyip test etme uygulamasıdır. Böylece tümleştirme sorunları sürüm anında değil, dakikalar içinde ortaya çıkar. Grady Booch terimi 1991'de önerdi, Kent Beck 1990'ların sonlarında bu uygulamayı Aşırı Programlama'nın temel bir parçası yaptı ve Martin Fowler'ın Continuous Integration makalesi bugün de çoğu ekibin izlediği iş akışını anlatıyor. Makine öğrenmesinde (ML) CI; verileri, eğitim kodunu ve model davranışını da denetler; çünkü bir değişiklik tüm birim testlerini geçirirken modelin doğruluğunu düşürebilir.

CI İşlem Hattı Nasıl Çalışır#

Bir geliştirici bir dalı gönderdiğinde veya çekme isteği açtığında, GitHub Actions, GitLab CI/CD ya da Jenkins gibi bir CI hizmeti yeni bir çalıştırıcı başlatır, kodu çalışma alanına çeker, bağımlılıkları yükler ve şu işlerden oluşan bir işlem hattı çalıştırır: lint ve tür denetimleri, birim testleri, tümleştirme testleri ve paketlerin ya da kapsayıcı görüntülerinin derlenmesi. Her iş, durumunu çekme isteğine iletir ve dal koruma kuralları, gerekli tüm denetimler geçene kadar birleştirmeyi engelleyebilir. İşlem hatları genellikle aynı testleri farklı işletim sistemi ve Python sürümlerinden oluşan bir matris üzerinde tekrarlar ve her birleştirmeden sonra ana dalda tüm test paketini yeniden çalıştırır. Hız da bu uygulamanın bir parçasıdır: Beck'in Aşırı Programlama yaklaşımı, tüm sistemi derlemek ve her testi çalıştırmak için on dakikalık bir hedef belirledi; çünkü daha yavaş bir derleme daha seyrek çalıştırılır.

Makine Öğrenmesi için CI#

ML projeleri kendi denetimlerini de ekler. Veri testleri, yeni eğitim verilerinin beklenen şemaya uyduğunu, her etiket dosyasının ayrıştırılabildiğini ve hiçbir görselin hem eğitim hem de doğrulama bölümlerinde bulunmadığını doğrular; aksi hâlde veri sızıntısı oluşur. Bir duman testi, biçim hatalarını ve çökmeleri dakikalar içinde yakalamak için küçük bir veri kümesinde tek bir epoch boyunca eğitim yapar. Model çıktılarının karşılaştırıldığı testlerde rastgele tohumlar sabitlenir ve küçük sayısal toleranslara izin verilir; çünkü GPU çekirdekleri ve veri yükleme sırası, kayan noktalı sonuçları çalıştırmadan çalıştırmaya değiştirebilir. Kalite eşiği, modeli sabit bir doğrulama kümesinde puanlar ve ortalama kesinlik ortalaması (mAP) gibi bir ölçüt belirli bir taban değerin altına düşerse derlemeyi başarısız sayar. Dışa aktarma testleri de modelin ONNX veya TensorRT sürümlerinin hâlâ yüklenip asıl model gibi puan verdiğini denetler. Tam eğitim yavaştır ve GPU çalıştırıcıları pahalıdır; bu nedenle ekipler genellikle her çekme isteğinde hızlı denetimleri çalıştırır, tam yeniden eğitimi ve model dağıtımını ise zamanlanmış çalıştırmalara veya ana dala bırakır. DVC gibi sürümleme araçları da her işin ihtiyaç duyduğu veri kümesinin tam sürümünü almasını sağlar.

Ultralytics YOLO'nun kıyaslama modu bu tür bir eşik denetimi görevi görür: verbose 0.216 gibi bir float değerine ayarlandığında, dışa aktarma başarısız olursa veya dışa aktarılan biçimlerden herhangi birinin mAP_50-95 değeri bu taban değeri aşmazsa hata verir. Ultralytics deposunun kendi CI sistemi, YOLO26 dışa aktarımlarını Linux, macOS ve ARM çalıştırıcılarında test etmek için bu özelliği kullanır. Birim testlerini bu eşik denetimiyle birleştiren en basit GitHub Actions iş akışı şöyledir:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

Her çekme isteğinde ve main dalına yapılan her gönderimde iş, yeni bir Ubuntu çalıştırıcısında çalışır. Başarısız birim testi veya küçük COCO8 veri kümesinde taban değerin altında ya da ona eşit puan alan ONNX modeli, değişiklik birleştirilmeden önce denetimi başarısız kılar.

CI, CD, MLOps ve Sürekli Eğitim#

• Sürekli teslimat (CD): CI denetimlerinden geçen derlemeleri yayına hazır tutar ve çoğu zaman bunları bir hazırlık ortamına otomatik olarak dağıtır. Sürekli dağıtım bir adım daha ileri gider ve başarılı her değişikliği üretim ortamına aktarır.
• MLOps: ML yaşam döngüsü boyunca CI ve CD'yi veri sürümleme, model dağıtımı, izleme ve yeniden eğitimle birleştiren daha geniş disiplin.
• Sürekli eğitim (CT): Yeni veriler geldiğinde veya izleme sapma tespit ettiğinde modeli otomatik olarak yeniden eğitir ve yeniden dağıtır. Google'ın MLOps olgunluk düzeylerinde otomatik yeniden eğitim 1. düzeyde, eğitim işlem hattının kendisi için otomatik CI/CD ise 2. düzeyde yer alır.