Backend, web ve mobil için GitHub Actions ile GitLab CI

Çoklu uygulama CI'de insanların zorlandığı noktalar

Bir depo backend, web uygulaması ve mobil uygulamalar derlediğinde CI artık sadece "testleri çalıştırmak" olmaktan çıkar. Farklı araç zincirleri, farklı derleme süreleri ve farklı yayın kuralları için bir trafik kontrolörüne dönüşür.

En yaygın sorun basittir: küçük bir değişiklik gereğinden fazla işi tetikler. Bir doküman değişikliği iOS imzalamayı başlatır veya bir backend düzeltmesi tüm web derlemesini zorunlu kılar ve bir anda her birleştirme yavaş ve riskli hissedilir.

Çoklu uygulama kurulumlarında birkaç problem erken görünür:

• Runner sürüklenmesi: SDK sürümleri makineler arasında farklı olur, bu yüzden derlemeler CI ile yerel arasında farklı davranır.
• Gizli bilgi yayılımı: API anahtarları, imzalama sertifikaları ve mağaza kimlik bilgileri işler ve ortamlar arasında çoğaltılır.
• Önbellek kafa karışıklığı: yanlış önbellek anahtarı eski derlemelere yol açar, ama önbellek yoksa her şey acılı bir şekilde yavaşlar.
• Karışık yayın kuralları: backend sık dağıtmak isterken mobil sürümler kontrol gerektirir ve ekstra kontroller ister.
• Pipeline okunabilirliği: yapılandırma dokunmak istemeyeceğiniz bir iş duvarına dönüşür.

Bu nedenle GitHub Actions ile GitLab CI arasındaki seçim, tek uygulamalı projelere göre monorepolarda daha fazla önem taşır. Yol, dosya bazlı iş bölme, artefakt paylaşımı ve paralel işlerin birbirine girmesini önlemenin net yollarına ihtiyacınız var.

Pratik bir karşılaştırma dört şeye iniyor: runner kurulumu ve ölçeklendirme, gizli bilgilerin saklanması ve kapsamı, önbellekleme ve artifactler, ve "sadece değişeni derle" demeyi pipeline'ı kırılgan kural çorbasına dönüştürmeden ne kadar kolay ifade edebildiğiniz.

Bu gündelik güvenilirlik ve sürdürülebilirlikle ilgili, hangi platformun daha çok entegrasyonu veya daha hoş bir arayüze sahip olduğu değil. Aynı zamanda build araçlarınız (Gradle, Xcode, Docker vb.) hakkındaki kararların yerini almaz. Hangi CI'nin temiz bir yapıyı korumayı kolaylaştırdığını seçmenize yardımcı olur.

GitHub Actions ve GitLab CI nasıl yapılandırılır

En büyük fark, her platformun pipeline'ları ve yeniden kullanılabilirliği nasıl organize ettiğiyle ilgilidir ve bu, backend, web ve mobil derlemeler aynı repoyu paylaşınca önem kazanmaya başlar.

GitHub Actions otomasyonu .github/workflows/ altındaki YAML dosyalarına koyar. Workflow'lar push, pull request, zamanlayıcı veya manuel çalıştırmalar gibi olaylarla tetiklenir. GitLab CI ise repo kökündeki .gitlab-ci.yml etrafında şekillenir; isteğe bağlı include dosyalarıyla ve pipeline'lar genellikle push, merge request, zamanlayıcı ve manuel işler ile çalışır.

GitLab sahne (stage) etrafında inşa edilmiştir. Siz sahneleri (build, test, deploy) tanımlarsınız, sonra işler sahnelere atanır ve sırayla çalışır. GitHub Actions ise job içeren workflow'lar etrafında kurulur. İşler varsayılan olarak paralel çalışır, bir şey beklemek zorundaysa bağımlılıklar eklersiniz.

Aynı mantığı birçok hedefte çalıştırmak için GitHub'un matrix derlemeleri doğal bir uyum sağlar (iOS vs Android, birden çok Node sürümü). GitLab benzer bir fan-out'u parallel işler ve değişkenlerle yapabilir, ama genellikle daha fazla şeyi kendiniz bağlarsınız.

Yeniden kullanım da farklı görünür. GitHub'da ekipler genellikle reusable workflows ve composite action'lara dayanır. GitLab'da tekrar kullanım genelde include, paylaşılan şablonlar ve YAML anchor/extends ile olur.

Onaylar ve korumalı ortamlar da farklıdır. GitHub genellikle production deployların onaylanana kadar duraklaması için required reviewer'lı korumalı ortamlar ve environment secret'lar kullanır. GitLab ise genelde korumalı branch/tag, korumalı ortamlar ve manuel işler kombinasyonuyla sadece belirli rollerin deploy çalıştırmasını sağlar.

Runner kurulumu ve iş çalıştırma

Runner kurulumu iki platformun günlük kullanımda farklı hissettirdiği yerdir. Her ikisi de hosted runner'lar (makineyi yönetmezsiniz) veya self-hosted runner'lar (makine sizde, güncellemeler ve güvenlik sizde) üzerinde işler çalıştırabilir. Hosted runner'lar başlamak için daha basittir; self-hosted runner'lar hız, özel araçlar veya iç ağa erişim gerektiğinde sıklıkla gereklidir.

Pek çok ekip için pratik bir ayrım: backend ve web için Linux runner'lar, iOS gerektiğinde sadece macOS runner'lar. Android Linux üzerinde çalışır ama ağırdır, bu yüzden runner boyutu ve disk alanı önemlidir.

Hosted vs self-hosted: neyi yönetirsiniz

Hosted runner'lar bakım olmadan öngörülebilir bir kurulum istediğinizde iyidir. Self-hosted runner'lar belirli Java/Xcode sürümleri, daha hızlı önbellekler veya iç ağ erişimi gerektiğinde mantıklıdır.

Self-hosted tercih ederseniz runner rollerini erken tanımlayın. Çoğu repo küçük bir setle iyi gider: backend/web için genel bir Linux runner, Android işleri için daha güçlü bir Linux runner, iOS paketleme ve imzalama için bir macOS runner ve daha sıkı izinlere sahip ayrı bir deploy runner.

İş başına doğru runner'ı seçmek

Her iki sistem de runner hedeflemeye izin verir (GitHub'da labels, GitLab'da tags). İsimlendirmeyi iş yüklerine göre bağlayın, örneğin linux-docker, android veya macos-xcode15 gibi.

İzolasyon birçok kırılgan derlemenin kaynağıdır. Kalan dosyalar, bozulmuş paylaşılan önbellekler veya self-hosted makinelerde elle kurulmuş araçlar rastgele hatalara yol açabilir. Temiz çalışma alanları, sabitlenmiş araç sürümleri ve planlı runner temizliği genellikle hızlı geri dönüş sağlar.

Kapasite ve izinler diğer yineleyen sorunlardır; özellikle macOS erişilebilirliği ve maliyetiyle. İyi bir varsayılan: build runner'ları derleyebilir, deploy runner'ları deploy yapabilir ve prodüksiyon kimlik bilgileri mümkün olan en küçük iş kümesinde yaşar.

Gizli bilgiler ve ortam değişkenleri

Gizli bilgiler çoklu uygulama CI pipeline'larında risklidir. Temel prensipler benzerdir (gizli bilgileri platformda saklayın, çalışma zamanında enjekte edin) ama kapsam farklı hissettirir.

GitHub Actions genelde gizli bilgileri repository ve organization düzeyinde scope eder, ayrıca bir Environment katmanı sunar. Bu Environment katmanı prodüksiyon için manuel bir kapı ve staging'den ayrı bir değer seti gerektiğinde faydalıdır.

GitLab CI proje, grup veya instance seviyesinde CI/CD değişkenleri kullanır. Ayrıca ortam bazlı değişkenleri destekler ve "protected" (sadece korumalı branch/tag'larda kullanılabilir) ve "masked" (loglarda gizlenir) gibi korumalar sağlar. Bu kontroller, bir monorepo birden fazla takıma hizmet ettiğinde kullanışlıdır.

Ana başarısızlık modu kazara sızmadır: debug çıktısı, değişkenleri yazdıran başarısız bir komut veya yanlışlıkla bir artifact içine dahil edilmiş bir config dosyası. Logları ve artifactleri paylaşıma açık kabul edin.

Backend + web + mobil pipeline'larında gizli bilgiler genellikle bulut kimlik bilgileri, veritabanı URL'leri ve üçüncü taraf API anahtarları, imzalama malzemesi (iOS sertifikaları/provisioning profilleri, Android keystore ve parolalar), registry token'ları (npm, Maven, CocoaPods) ve otomasyon token'ları (email/SMS sağlayıcıları, chat botlar) içerir.

Birden çok ortam (dev, staging, prod) için adları tutarlı tutun ve değerleri ortam kapsamına göre değiştirin, kopyalamayın. Bu, rotasyon ve erişim kontrolünü yönetilebilir kılar.

Birkaç kural çoğu olayı engeller:

• Kısa ömürlü kimlik bilgilerini tercih edin (mümkünse bulut sağlayıcılarına OIDC gibi) uzun ömürlü anahtarlar yerine.
• En az ayrıcalık: backend, web ve mobil için ayrı deploy kimlikleri kullanın.
• Gizli bilgileri maskelenmiş tutun ve ortam değişkenlerini yazdırmaktan kaçının, hatta hatalarda bile.
• Prodüksiyon gizli bilgilerini korumalı branch/tag'lara ve gerekli onaylara kısıtlayın.
• Gizli bilgileri build artifactlerine, geçici olsa bile, asla koymayın.

Basit, yüksek etkili bir örnek: mobil işler imzalama gizli bilgilerini yalnızca etiketlenmiş sürümlerde almalı, backend deploy işleri ise main'e merge'lerde sınırlı bir deploy token kullanabilir. Bu değişiklik tek başına yanlış yapılandırılmış bir işin patlama alanını ciddi şekilde azaltır.

Daha hızlı derlemeler için önbellekleme ve artifactler

Çoğu yavaş pipeline sıkıcı bir sebepten yavaştır: aynı şeyleri tekrar tekrar indirir ve yeniden derler. Önbellekleme tekrar işi önler. Artifactler ise farklı bir problemi çözer: belirli bir çalışmadan gelen tam çıktıları saklamak.

Ne önbellekleneceği yaptığınız işe bağlıdır. Backendler bağımlılık ve derleyici önbelleklerinden fayda sağlar (ör. Go module cache). Web derlemeleri paket yöneticisi ve build araç önbelleklerinden fayda görür. Mobil derlemeler genellikle Linux üzerinde Gradle artı Android SDK önbelleği ve macOS'ta CocoaPods veya Swift Package Manager önbelleği ister. iOS DerivedData gibi agresif build çıktısı önbelleklemesi konusunda dikkatli olun; taraflarını anlamadan kullanmayın.

Her iki platform da aynı temel deseni takip eder: işin başında önbelleği geri yükle, sonunda güncellenmiş önbelleği kaydet. Günlük fark kontroltedir. GitLab önbellek ve artifact davranışını tek dosyada açıkça belirtme eğilimindedir, süresi dahil. GitHub Actions ise genellikle önbellekleme için ayrı action'lara dayanır; bu esnek ama yanlış yapılandırılması daha kolaydır.

Monorepolarda önbellek anahtarları daha önemlidir. İyi anahtarlar girdiler değiştiğinde değişir, aksi halde sabit kalır. Lockfile'lar (go.sum, pnpm-lock.yaml, yarn.lock vb.) anahtarı sürmeli. Ayrıca, repo bütününün yerine derlediğiniz belirli uygulama klasörünün hash'ini eklemek ve uygulama başına ayrı önbellek tutmak, bir değişikliğin her şeyi geçersiz kılmamasına yardımcı olur.

Artifactleri saklamak istediğiniz teslimatlar için kullanın: sürüm paketleri, APK/IPA çıktıları, test raporları, coverage dosyaları ve build meta verisi. Önbellekler hızlandırma amaçlıdır; artifactler kayıt amaçlı.

Derlemeler hâlâ yavaşsa, aşırı büyük önbelleklere, her çalışmada değişen anahtarlara (zaman damgaları ve commit SHA'ları yaygın suçlulardır) ve runner'lar arasında yeniden kullanılamayan önbelleğe alınmış build çıktılara bakın.

Monorepo uyumu: karmaşa olmadan birden çok pipeline

Bir monorepo, her push'un backend testlerini, web derlemelerini ve mobil imzalamayı tetiklemesiyle karışır; oysa siz sadece bir README değiştirmiş olabilirsiniz. Temiz desen: ne değiştiğini tespit edin, sadece ilgili işleri çalıştırın.

GitHub Actions'da bu genellikle her uygulama için ayrı workflow'lar ve yol filtreleri kurmak demektir, böylece her workflow sadece kendi alanındaki dosyalar değiştiğinde çalışır. GitLab CI'de ise genellikle tek bir pipeline dosyası içinde rules:changes (veya child pipeline'lar) ile yollar bazlı olarak iş gruplarını oluşturmak veya atlamak yaygındır.

Paylaşılan paketler güvenin bozulduğu yerdir. Eğer packages/auth değişirse, backend ve web her ne kadar kendi klasörleri değişmemiş olsa da yeniden derlenmeye ihtiyaç duyabilir. Paylaşılan yolları birden fazla pipeline için tetikleyici olarak ele alın ve bağımlılık sınırlarını net tutun.

Sürprizleri azaltan basit bir tetik haritası:

• Backend işler backend/** veya packages/** içindeki değişikliklerde çalışsın.
• Web işler web/** veya packages/** içindeki değişikliklerde çalışsın.
• Mobil işler mobile/** veya packages/** içindeki değişikliklerde çalışsın.
• Sadece doküman değişiklikleri hızlı bir kontrol çalıştırsın (format, yazım denetimi).

Güvenli olanları paralelleştirin (unit test, lint, web build). Kontrol edilmesi gerekenleri sıraya koyun (deploylar, app store sürümleri). Hem GitLab'ın needs hem de GitHub job bağımlılıkları hızlı kontrolleri erkenden çalıştırıp başarısız olunca geri kalan işlemleri durdurmanıza yardımcı olur.

Mobil imzalamayı günlük CI'den izole tutun. İmzalama anahtarlarını adaya ait bir ortama koyun, manuel onay gerektirin ve imzalamayı sadece etiketlenmiş sürümlerde çalıştırın. Normal pull requestler yine imzasız uygulamalar derleyebilir; böylece hassas kimlik bilgilerini maruz bırakmadan doğrulama yapabilirsiniz.

Adım adım: backend, web ve mobil için temiz bir pipeline

Temiz bir çoklu uygulama pipeline'ı niyeti açıkça belli eden isimlendirmeyle başlar. Bir desen seçin ve ona sadık kalın ki insanlar loglara bakınca neyin çalıştığını anlatsın.

Okunaklı kalan bir şema:

• Pipeline'lar: pr-checks, main-build, release
• Ortamlar: dev, staging, prod
• Artifactler: backend-api, web-bundle, mobile-debug, mobile-release

Bundan sonra işleri küçük tutun ve sadece önceki kontrolleri geçenleri terfi ettirin:

1. PR kontrolleri (her pull request): değişen uygulamalar için hızlı testleri ve lint'i çalıştırın. Backend için deploy edilebilir bir artifact (container image veya server bundle) oluşturun ve daha sonraki adımların yeniden derlememesi için saklayın.

2. Web derlemesi (PR + main): web uygulamasını statik bir bundle olarak derleyin. PR'lerde çıktıyı artifact olarak saklayın (veya bir preview ortama deploy edin). Main'de ise dev veya staging için sürümlenmiş bir bundle üretin.

3. Mobil debug derlemeleri (sadece PR): debug APK/IPA oluşturun. Release için imzalamayın. Amaç hızlı geri bildirim ve test edilebilen bir dosya sağlamaktır.

4. Release derlemeleri (sadece etiketler): v1.4.0 gibi bir etiket itildiğinde, tam backend ve web derlemeleri ile imzalı mobil release derlemelerini çalıştırın. Mağaza hazır çıktılar üretin ve release notlarını artifactlerle birlikte saklayın.

5. Manuel onaylar: staging ile prod arasına onay koyun; temel testlerin öncesine değil. Geliştiriciler derlemeleri tetikleyebilir, ama yalnızca onaylı roller prodüksiyona deploy edip prodüksiyon gizli bilgilerine erişebilsin.

Zaman kaybettiren yaygın hatalar

Ekipler genellikle kırılgan build'lar yaratan iş alışkanlıklarına haftalar kaybeder.

Bir tuzak çok paylaşılan runner'lara fazla bel bağlamaktır. Birçok proje aynı havuzla yarıştığında rastgele zaman aşımı, yavaş işler ve mobil derlemelerin sadece yoğun saatlerde başarısız olması gibi sorunlar yaşanır. Backend, web ve mobil derlemeler önemliyse ağır işleri ayrı runner'larda (veya en azından farklı kuyruklarda) izole edin ve kaynak limitlerini açıkça belirtin.

Gizli bilgiler başka bir zaman tuzağıdır. Mobil imzalama anahtarları ve sertifikaları yanlış yönetilmesi kolaydır. Yaygın bir hata onları çok geniş şekilde saklamaktır (her branch ve işe erişilebilir) veya çok ayrıntılı loglarla sızdırmaktır. İmzalama malzemesini korumalı branch/tag'lara sınırlayın ve gizli değerleri (base64 dahil) yazdıran adımlardan kaçının.

Önbellekleme büyük klasörleri önbelleğe almak veya cache ile artifactleri karıştırmak ters tepebilir. Sadece kararlı girdileri önbelleğe alın. Daha sonra ihtiyaç duyduğunuz çıktıları artifact olarak saklayın.

Son olarak, monorepolarda her değişiklikte her pipeline'ı tetiklemek dakikaları ve sabrı yakar. Birisi README'yi düzeltip iOS, Android, backend ve web yeniden derleniyorsa insanlar CI'ye güvenmeyi bırakır.

Kısa bir kontrol listesi yardımcı olur:

• Yol tabanlı kurallar kullanın ki sadece etkilenen uygulamalar çalışsın.
• Test işleri ile deploy işlerini ayırın.
• İmzalama anahtarlarını release workflow'larına sınırlayın.
• Küçük, kararlı girdileri önbelleğe alın; tüm build klasörlerini değil.
• Ağır mobil derlemeler için öngörülebilir runner kapasitesi planlayın.

Bir platforma karar vermeden önce hızlı kontroller

Seçmeden önce günlük çalışmanızı yansıtan birkaç kontrol yapın. Bu, bir uygulama için iyi görünen ama mobil derlemeler, birden çok ortam ve sürümler eklendiğinde canınızı yakacak bir aracı seçmenizi engeller.

Odaklanın:

• Runner planı: hosted, self-hosted veya karışık. Mobil derlemeler genellikle macOS gerektiği için ekipleri karışıma yönlendirir.
• Gizli bilgiler planı: gizli bilgiler nerede saklanıyor, kim okuyabiliyor ve rotasyon nasıl işliyor. Prodüksiyon staging'den daha sıkı olmalı.
• Önbellek planı: neyi önbelleğe alıyorsunuz, nerede saklanıyor ve anahtarlar nasıl oluşturuluyor. Anahtar her committe değişiyorsa maliyeti ödersiniz ama hızlanmazsınız.
• Monorepo planı: yol filtreleri ve ortak adımları (lint, test) kopyala-yapıştır olmadan paylaşmanın temiz yolu.
• Sürüm planı: etiketler, onaylar ve ortam ayrımı. Prodüksiyona kim terfi ettirebilir ve hangi kanıt gerekir netleştirin.

Bu cevapları küçük bir senaryoyla baskılayın. Bir monorepoda Go backend, Vue web uygulaması ve iki mobil uygulama varsa: doküman-only değişiklik neredeyse hiçbir şey yapmamalı; backend değişikliği backend testlerini çalıştırıp bir API artifacti oluşturmalı; mobil UI değişikliği yalnızca Android ve iOS derlemelerini başlatmalı.

Bu akışı bir sayfada tarif edemiyorsanız (tetikleyiciler, önbellekler, gizli bilgiler, onaylar), aynı repo üzerinde her iki platformda bir haftalık pilot çalıştırın. Sizi sıkıcı ve öngörülebilir hissettiren platformu seçin.

Örnek: gerçekçi bir monorepo derleme ve yayın akışı

Bir depoda üç klasör olduğunu düşünün: backend/ (Go), web/ (Vue) ve mobile/ (iOS ve Android).

Günlük olarak hızlı geri bildirim istersiniz. Yayınlarda tam derlemeler, imzalama ve yayın adımları istersiniz.

Pratik bir ayrım:

• Feature branch'ler: değişen kısımlar için lint + unit test çalıştırın, backend ve web'i derleyin ve isteğe bağlı olarak bir Android debug derlemesi yapın. iOS'u sadece gerçekten gerektiğinde çalıştırın.
• Release etiketleri: her şeyi çalıştırın, sürümlenmiş artifactler oluşturun, mobil uygulamaları imzalayın ve görüntü/binary'leri sürüm depolamanıza gönderin.

Mobil devreye girince runner seçimi değişir. Go ve Vue Linux üzerinde rahat çalışır. iOS macOS runner gerektirir; bu karar çoğu zaman her şeyden daha belirleyici olur. Eğer takım makine kontrolüne tam sahip olmak istiyorsa, GitLab CI ve self-hosted runner'ları bir filo olarak çalıştırmak daha kolay olabilir. Daha az operasyonel iş ve hızlı kurulum tercih ediyorsanız, GitHub hosted runner'lar uygundur, ama macOS dakika maliyetleri ve erişilebilirlik planlamanıza dahil olur.

Önbellekleme gerçek zaman kazandırır, ama en iyi önbellek uygulamaya göre değişir. Go için module indirmelerini ve build cache'i önbelleğe alın. Vue için paket yöneticisi deposunu önbelleğe alın ve lockfile değişmediğinde yeniden derleyin. Mobilde Linux'ta Gradle ve Android SDK, macOS'ta CocoaPods veya SwiftPM önbellekleri kullanın; daha büyük önbellekler ve daha fazla invalidasyon bekleyin.

Bir karar kuralı: kodunuz zaten bir platformda barınıyorsa oradan başlayın. Sadece runnerlar (özellikle macOS), izinler veya uyumluluk sizi zorlamazsa taşın.

Sonraki adımlar: seçin, standartlaştırın ve güvenli şekilde otomatikleştirin

Kodunuzun ve ekiplerinizin bulunduğu aracı seçin. Çoğu zaman fark günlük sürtüşmede ortaya çıkar: incelemeler, izinler ve bozulan bir derlemeyi kimin ne kadar hızlı teşhis edebildiği.

Basit başlayın: uygulama başına bir pipeline (backend, web, mobile). Stabil olunca ortak adımları yeniden kullanılabilir şablonlara çekin ki kopyala-yapıştırı azaltın ama sahipliği bulanıklaştırmayın.

Gizli bilgi kapsamlarını ofis anahtarlarının kimde olduğunu yazdığınız gibi belgeler gibi yazın. Prodüksiyon gizli bilgileri her branch tarafından okunmamalı. Rotasyon hatırlatıcısı ayarlayın (üç aylık, hiç yapmamaktan iyidir) ve acil iptallerin nasıl yapılacağını kararlaştırın.

Eğer no-code bir jeneratör kullanıp gerçek kaynak kod üretiyorsanız, üretim/dışa aktarma adımını CI'de birinci sınıf adım olarak ele alın. Örneğin AppMaster (appmaster.io) Go backend, Vue3 web uygulamaları ve Kotlin/SwiftUI mobil uygulamaları üretiyorsa pipeline kodu yeniden üretebilir, sonra yalnızca üretim sonrası gerçekte değişen hedefleri derleyebilirsiniz.

Takımınızın güvendiği bir akışı varsayılan yapın: temiz tetikleyiciler, öngörülebilir runner'lar, sıkı gizli bilgiler ve yalnızca istediğinizde çalışan yayınlar.