Geliştirdiğiniz sürümü paketleyin ve üretime taşıyın

Geliştirmede denediğiniz kodun çalışan sürüme geçmesi üç ayrı kayıt üzerinden izlenir: kaydedilmiş dosya → Git commit’i → dağıtılmış imaj. Birinin güncellenmesi diğerlerinin de güncellendiği anlamına gelmez. Bu rehber önce bir deneme projesinde iki sürümün dağıtımını ve test edilen build’in sürüm yapılmasını, sonra sürümün başka bir ortama dağıtılmasını ve önceki sürüme dönüşü açıklar.

Temel düğme davranışları Run/Reload/Build rehberinde, commit işlemi Git rehberinde, çalışan sürümün incelenmesi Deployment/Log rehberindedir.

Çalışan sistem yeni kodu nereden alır?

Paketlenmiş runtime, Git dalını izleyip her push’ta kaynak kodunu yeniden yüklemez. Varsayılan Build, seçili commit’ten imaj üretip registry’ye gönderir ve mevcut kurulumun Kubernetes namespace’inde dağıtımı uygular. Kaynakları Git’ten okuyan builder, imajı registry’den alıp çalıştıran Kubernetes’tir.

Build başladıktan sonra başka bir commit gelmesi o build’in seçili kaynağını değiştirmez. İmaj etiketi girilmez: Build imajı projenin son commit’inin kısa (7 karakterlik) kimliğiyle, commit yoksa latest ile etiketler. Dağıtım etiketi değil, imajın digest’ini kullanır.

1. Deneme projesinde v1 oluşturun

Bu örneği geliştirme ortamında ayrı bir projede uygulayın. Dış sisteme veri yazmaz; runtime her başladığında bir kez log üretir. Ön koşullar: geliştirici yetkisi, Git/registry erişimi ve çalışan build altyapısı.

1. Projects → Create project ile Release greeting / release-greeting projesi oluşturun.
2. Source → Files → Create file ile greeting.camel.yaml ekleyin:

- route:
    id: release-greeting
    description: Report the greeting version
    from:
      uri: timer:releaseGreeting
      parameters:
        delay: 3000
        repeatCount: 1
      steps:
        - setBody:
            constant: Hello v1
        - log:
            message: 'RELEASE-CHECK: ${body}'

3. Saved durumunu bekleyin. İsterseniz Set Body ve Logger bölümünü önce Simulate ile deneyin.
4. Run seçin; Log içindeki doğru devmode container’ında RELEASE-CHECK: Hello v1 satırını bulun.
5. Gerçek projenizde ayrıca giriş isteğini, dış bağlantıları, hata senaryosunu ve iş sonucunu doğrulayın. Bu küçük örnek yalnız sürüm aktarımını öğretir.

Timer repeatCount: 1 olduğundan sürekli çıktı beklemeyin. Runtime yeniden başladığında yeniden tetiklenir; bu örnek küme genelinde yalnız bir kez çalışan bir iş garantisi vermez.

2. Kaydedilmiş sürümü Git’e gönderin

1. Source → Files altında kaynakları ve değişiklik farklarını inceleyin.
2. Route, application.properties, deployment.jkube.yaml ve diğer gereken dosyaları seçin. Gerçek projede script, Kamelet, OpenAPI ve api-publishing.yaml dosyalarını da kontrol edin.
3. Push (n) → Commit message alanına Add greeting release v1 yazın; Commit and push seçin. Mesajın ilk satırı, bu commit’ten yapılan sürümü Releases tablosunda adlandırır; neyin değiştiğini anlatan kısa bir cümle yazın.
4. Source → Commits ve Last commit bilgisinden commit kimliğini kaydedin.

Saved, dosyanın kaydıdır; Last commit dağıtılacak sürümü gösterir. Seçilmemiş değişiklikler Build’e dahil olmaz. Dosya silmeleri de Git’e giden değişiklikler olduğundan farkları kontrol edin.

3. Aynı ortamda paketlenmiş v1’i çalıştırın

1. Geliştirme çalışmasını Delete container ile sonlandırın.
2. Build sekmesini açın. İmaj yeni commit’in kısa kimliğiyle etiketlenir.
3. Build seçin ve Build completed sonucunu bekleyin. Varsayılan akış bu ortamda dağıtım da yapar; sonuç ancak tüm replica’lar yeni sürümü çalıştırdığında görünür.
4. Deployment sekmesinin Runtime tablosunda açıklamanın An unreleased build is deployed in dev. olduğunu, yeni podun Version sütununda Unreleased build gösterdiğini ve durumunu kontrol edin. Pod olayları için satırı genişletin.
5. Log’da packaged container’ı seçin; RELEASE-CHECK: Hello v1 sonucunu bulun.

Bu noktada geliştirme namespace’inde paketlenmiş bir sürüm çalışır. Bu işlem, başka bir ortama geçiş yapıldığını göstermez. Build’in ardından ayrıca bir Deploy gerekmez.

Build isteğinin kabul edilmesi tamamlanma değildir. Builder hata verdiyse hangi aşamada durduğunu bulun; registry’ye imaj yazılmış olsa da Kubernetes veya API yayını aşaması başarısız olabilir. Yeni sürüm hazır olmazsa Build failed Kubernetes’in nedenini (kota, zamanlama, imaj çekme veya readiness mesajı) gösterir; önceki sürüm hizmet vermeye devam eder ve Lunex bu ortamdaki son başarılı paketi geri yükler. Runtime inceleme hangi kanıtın nerede bulunduğunu gösterir.

4. v2’yi dağıtın ve eski sürümle karıştırmayın

1. Kaynakta yalnız Hello v1 değerini Hello v2 yapın; Saved durumunu bekleyin.
2. Set Body’yi Simulate ile deneyin. Bu, packaged v1’i güncellemez.
3. Değişikliği Update greeting to v2 mesajıyla commit edip gönderin; yeni commit kimliğini not edin.
4. Yeniden Build yapın; imaj yeni commit’in kısa kimliğiyle etiketlenir. Deployment’ta yeni podun Started zamanını ve durumunu, Log’da RELEASE-CHECK: Hello v2 satırını doğrulayın.

Kaynakta v2 yazarken eski packaged v1’in çalışması normaldir; onu değiştiren başarılı dağıtım adımıdır. Gerçek entegrasyonlarda kod değişikliğini deneme ortamında gerçek giriş ve dış bağlantıyla da doğrulayın. Aynı proje için packaged runtime mevcutken Run sunulmayabilir; üretim servisini kaldırarak geliştirme alanı açmak yerine geliştirme ortamını kullanın.

5. Test edilen build’i Create release ile sürüm yapın

dev kurulumunda Build’in dağıttığı ve denediğiniz paket, Deployment → Releases → Create release ile değişmeyen, numaralı bir sürüm (release) olur.

1. Runtime tablosunun açıklamasına bakın. An unreleased build is deployed in dev., bu ortamda çalışan build’in henüz sürüm olmadığını gösterir.
2. Releases araç çubuğunda Create release seçin; Create release onayında yeniden Create release seçin.
3. Sonuç gelene kadar Releases araç çubuğunda Create release yerine Creating release… görünür ve işlem ikinci kez gönderilemez. Create release completed bildiriminden sonra açıklama Release 1 is deployed in dev. olur; sürüm Releases tablosunda commit mesajıyla ve Deployed etiketiyle görünür, podların Version sütunu Release 1 olur. Başarısızlıkta sekmenin üstündeki Create release failed bildirimi sunucunun nedenini gösterir ve düğme yeniden kullanılabilir.

Sürüm numarasını Lunex verir: projenin Git’teki son sürüm etiketinin bir fazlası. Numara elle yazılmaz ve yeniden kullanılmaz. Sürüm, bu ortamın sürüm kaydındaki paketin birebir kopyasıdır. İmaj digest ile, kaynak commit’i ve platform sürümü paketin içindedir. Namespace, servis hesabı ve Message Monitor bağlantısı gibi ortam değerleri pakette yoktur; her kurulum kendi değerlerini dağıtım sırasında ekler.

Git’te bir sürüm iki kayıttır: çalışma dalıyla ortak geçmişi olmayan releases dalındaki <proje>.yaml dosyası ve o commit’i gösteren <proje>/<numara> açıklamalı etiketi. İkisi tek bir atomik push ile gönderilir; proje dalınıza commit eklenmez. Etiket mesajı yalnız okunabilir metindir (Release 1 of release-greeting); Lunex bu mesajdan veri okumaz. Oluşan sürüm değişmez ve Lunex hiçbir push’u zorlamaz.

Create release yalnız dev kurulumunda görünür ve bu ortamda sürüm adı olmayan bir build çalışırken, başka işlem sürmüyorsa etkindir. Build yoksa veya çalışan build zaten bir sürümse devre dışıdır; diğer kurulumlar isteği sunucuda reddeder. Aynı commit’i örneğin platform yükseltmesinden sonra yeniden build ederseniz yeni imaj yeni bir numarayla sürüm olur. İki kişi aynı anda Create release seçerse her biri ayrı numara alır: Git’in reddettiği push güncel duruma göre yeniden denenir, var olan etiket değiştirilmez. Create release; Build dağıtımı, Deploy, Restart ve Undeploy ile aynı proje kilidini kullanır, biri sürerken diğeri reddedilir. Sürümün Git yazarı sizsiniz ve Created by sütunu sizi gösterir; hesabınızda e-posta adresi yoksa istek commit’te olduğu gibi reddedilir.

6. Sürümü başka bir ortama dağıtın

Her ortam, örneğin prod, kendi Lunex kurulumudur. Platform yöneticisi bu kurulumu dev’in Git deposuna ve imaj registry’sine erişecek biçimde kurar; salt okunur Git erişimi yeterlidir. Prod kurulumu build yapmaz ve Git’e yazmaz.

1. Projeyi ortama bir kez alın: proje bu ortamda henüz yoksa Projects listesinde Pull seçin. Bu yalnız ilk sürüm için gerekir; sonraki sürümler Pull olmadan görünür.
2. Sürümü seçin: projenin Deployment sekmesindeki Releases tablosu sürümleri Git’ten, en yenisi üstte listeler. Commit message, Created ve Created by sütunlarıyla dev’de test ettiğiniz sürümü bulun. Deployed etiketi bu ortamda çalışan sürümü gösterir.
3. Dağıtın: satırda Deploy seçip Deploy release <numara> onayını verin. Çalışan sürüm silinmez; yenisi hazır olana kadar hizmet verir.
4. Sonucu bekleyin: Deploying release <numara>… süresince sürümün satırında Deploying görünür ve aynı projede başka işlem gönderilemez. Deploy of release <numara> completed tüm replica’lar yeni sürümü çalıştırdığında görünür.
5. Çalışan sürümü doğrulayın: Runtime tablosunda podların Version sütununda Release <numara> gösterdiğini ve pod olaylarını, Log’da başlangıcı ve kontrollü bir iş isteğini kontrol edin. API varsa doğru dış URL, kimlik doğrulama ve route sonucunu da doğrulayın; API yayınlama prosedürünü tamamlayın.

Sürüm ortam değeri içermez. Namespace, servis hesabı ve Message Monitor bağlantısını dağıtan kurulum ekler. Bağlantı adresleri ve parolalar gibi proje değerlerini {{secret:ad/anahtar}} veya {{configmap:ad/anahtar}} başvurularıyla yazın; her ortam bu Secret ve ConfigMap’leri kendi değerleriyle tutar. Geliştirme credential’larını kaynakla taşımayın.

Yeni sürüm hazır olmazsa önceki sürüm hizmet vermeye devam eder ve Lunex bu ortamda son başarılı paketi geri yükler; sekmenin üstündeki Deploy of release <numara> failed, the previous version runs again bildirimi Kubernetes’in nedenini gösterir. Kota veya kapasite yetersizliği de bu yolla bildirilir ve yeni sürümdeki bir hata anlamına gelmez. Daha yeni bir Lunex ile build edilmiş sürüm Requires Lunex <sürüm> gösterir ve dağıtılamaz; daha eski bir Lunex ile build edilmiş sürüm Rebuild required · built by <sürüm> gösterir ama dağıtılabilir. Ayrıntılar çalıştırma ve dağıtım sayfasındadır.

Önceki sürüme dönün

Önceki sürüme dönmek, Releases tablosunda o sürümü Deploy etmektir. Aynı adımlar, aynı ilerleme ve aynı otomatik geri yükleme geçerlidir; ayrı bir geri alma düğmesi yoktur. Kaynağı da geri almak gerekiyorsa Git aracınızda değişikliği geri alan yeni bir commit hazırlayın, dev’de Build edip yeni bir sürüm yapın. Lunex’teki Commits ekranı dağıtım geri alma aracı değildir.

Sürüm değiştirmek veritabanı şema/veri değişikliklerini veya dış sisteme gönderilmiş mesajları geri almaz. Bu tür etkilerin geri dönüşü iş sürecinin parçasıdır.

Yeni kod görünmüyorsa

Çalıştırma rehberi, Git ve Deployment/Log üzerinden ilgili adıma dönün.