Modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde CI\/CD ara\u00e7lar\u0131, h\u0131z ve g\u00fcvenilirli\u011fi bir arada sunarak ekiplerin hayat\u0131n\u0131 kolayla\u015ft\u0131r\u0131yor. Peki, GitHub Actions m\u0131 yoksa GitLab CI m\u0131? Bu iki pop\u00fcler platformu derinlemesine inceleyerek, her birinin g\u00fc\u00e7l\u00fc ve zay\u0131f y\u00f6nlerini, kullan\u0131m senaryolar\u0131n\u0131 ve benim ki\u015fisel perspektifimi ke\u015ffedin.<\/p>\n
G\u00fcn\u00fcm\u00fcz h\u0131zla de\u011fi\u015fen teknoloji d\u00fcnyas\u0131nda, yaz\u0131l\u0131m geli\u015ftirme ekipleri s\u00fcrekli olarak daha h\u0131zl\u0131, daha g\u00fcvenilir ve daha verimli \u00e7al\u0131\u015fman\u0131n yollar\u0131n\u0131 ar\u0131yor. \u0130\u015fte tam da bu noktada S\u00fcrekli Entegrasyon (Continuous Integration – CI) ve S\u00fcrekli Teslimat\/Da\u011f\u0131t\u0131m (Continuous Delivery\/Deployment – CD) devreye giriyor. CI\/CD pratikleri, geli\u015ftiricilerin kod de\u011fi\u015fikliklerini otomatik olarak test etmesini, derlemesini ve da\u011f\u0131tmas\u0131n\u0131 sa\u011flayarak, manuel hatalar\u0131 en aza indirir ve \u00fcr\u00fcnlerin pazara \u00e7\u0131k\u0131\u015f s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r. Bir proje \u00fczerinde \u00e7al\u0131\u015fan ekip \u00fcyeleri aras\u0131nda tutarl\u0131l\u0131k sa\u011flamak, erken a\u015famada hatalar\u0131 tespit etmek ve s\u00fcrekli geri bildirim d\u00f6ng\u00fcleri olu\u015fturmak CI\/CD’nin temel faydalar\u0131 aras\u0131ndad\u0131r. Ancak, bu kadar hayati bir s\u00fcre\u00e7 i\u00e7in do\u011fru arac\u0131 se\u00e7mek, \u00e7o\u011fu zaman teknik liderler ve geli\u015ftiriciler i\u00e7in kafa kar\u0131\u015ft\u0131r\u0131c\u0131 bir karar olabilir. Piyasada bir\u00e7ok g\u00fc\u00e7l\u00fc CI\/CD arac\u0131 bulunsa da, GitHub Actions ve GitLab CI, entegrasyon yetenekleri, esneklikleri ve geni\u015f kullan\u0131c\u0131 tabanlar\u0131 sayesinde \u00f6ne \u00e7\u0131kan iki ana akt\u00f6rd\u00fcr. Her iki platform da kendi i\u00e7inde benzersiz avantajlar sunarken, projenizin \u00f6zel ihtiya\u00e7lar\u0131, ekibinizin al\u0131\u015fkanl\u0131klar\u0131 ve uzun vadeli stratejileriniz bu karar\u0131 do\u011frudan etkileyecektir. Bu makalede, bu iki dev platformu derinlemesine inceleyerek, teknik \u00f6zelliklerini kar\u015f\u0131la\u015ft\u0131racak, ger\u00e7ek d\u00fcnya senaryolar\u0131yla somutla\u015ft\u0131racak ve nihayetinde sizin i\u00e7in en uygun se\u00e7ene\u011fi belirlemenize yard\u0131mc\u0131 olacak kapsaml\u0131 bir analiz sunaca\u011f\u0131m. Amac\u0131m, sadece ara\u00e7lar\u0131n \u00f6zelliklerini listelemek de\u011fil, ayn\u0131 zamanda bu ara\u00e7lar\u0131 kullan\u0131rken edindi\u011fim deneyimler ve bak\u0131\u015f a\u00e7\u0131mla, bu karma\u015f\u0131k tercihi sizin i\u00e7in daha anla\u015f\u0131l\u0131r hale getirmektir. Bu y\u00fczden, gelin birlikte bu modern yaz\u0131l\u0131m geli\u015ftirme yolculu\u011funa \u00e7\u0131kal\u0131m ve GitHub Actions ile GitLab CI aras\u0131ndaki farklar\u0131 yak\u0131ndan inceleyelim.<\/p>\n
Bir yaz\u0131l\u0131m projesinde ba\u015far\u0131l\u0131 olmak, yaln\u0131zca harika kod yazmakla s\u0131n\u0131rl\u0131 de\u011fildir; ayn\u0131 zamanda bu kodu h\u0131zl\u0131, tutarl\u0131 ve hatas\u0131z bir \u015fekilde son kullan\u0131c\u0131lara ula\u015ft\u0131rabilmekle de yak\u0131ndan ilgilidir. \u0130\u015fte tam bu noktada, yaz\u0131l\u0131m geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn ayr\u0131lmaz bir par\u00e7as\u0131 haline gelen CI\/CD kavramlar\u0131 devreye girer. Peki, bu pop\u00fcler terimler tam olarak ne anlama geliyor ve neden g\u00fcn\u00fcm\u00fcz DevOps k\u00fclt\u00fcr\u00fcn\u00fcn temel ta\u015flar\u0131ndan biri olarak kabul ediliyorlar? \u00d6ncelikle, S\u00fcrekli Entegrasyon (Continuous Integration – CI) ile ba\u015flayal\u0131m. CI, geli\u015ftiricilerin kodlar\u0131n\u0131 s\u0131k s\u0131k, genellikle g\u00fcnde birka\u00e7 kez, ana kod taban\u0131na birle\u015ftirmesi anlam\u0131na gelir. Her bir birle\u015ftirme i\u015flemi sonras\u0131nda, otomatik testler \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Bu yakla\u015f\u0131m\u0131n temel amac\u0131, entegrasyon hatalar\u0131n\u0131 m\u00fcmk\u00fcn olan en erken a\u015famada tespit etmek ve \u00e7\u00f6zmektir. Manuel entegrasyon s\u00fcre\u00e7lerinde ortaya \u00e7\u0131kabilecek \u00e7ak\u0131\u015fmalar\u0131, uyumluluk sorunlar\u0131n\u0131 ve hatalar\u0131 azaltarak, ekiplerin daha sorunsuz bir \u015fekilde i\u015fbirli\u011fi yapmas\u0131n\u0131 sa\u011flar. Daha da \u00f6nemlisi, CI sayesinde geli\u015ftiriciler, kodlar\u0131n\u0131n ana dallarla ne kadar uyumlu oldu\u011funu s\u00fcrekli olarak g\u00f6r\u00fcrler, bu da g\u00fcveni art\u0131r\u0131r ve karma\u015f\u0131k sorunlar\u0131n birikmesini engeller. B\u00f6ylece, k\u00fc\u00e7\u00fck de\u011fi\u015fikliklerin etkileri an\u0131nda g\u00f6zlemlenebilir ve potansiyel riskler h\u0131zla bertaraf edilebilir. CI, tak\u0131m i\u00e7indeki ileti\u015fimi ve i\u015fbirli\u011fini de te\u015fvik ederken, yaz\u0131l\u0131m\u0131n s\u00fcrekli olarak \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131n\u0131 garantiler.<\/p>\n
S\u0131rada S\u00fcrekli Teslimat (Continuous Delivery – CD) ve S\u00fcrekli Da\u011f\u0131t\u0131m (Continuous Deployment – CD) var. Bu iki kavram genellikle birbirinin yerine kullan\u0131lsa da, aralar\u0131nda \u00f6nemli bir fark bulunur. S\u00fcrekli Teslimat (CD), kod de\u011fi\u015fikliklerinin test edildikten ve ana dallara entegre edildikten sonra, her an \u00fcretime da\u011f\u0131t\u0131labilecek durumda olmas\u0131n\u0131 garanti eder. Yani, t\u00fcm de\u011fi\u015fiklikler derlenir, test edilir ve da\u011f\u0131t\u0131ma haz\u0131r bir yap\u0131 (artifact) olarak bekletilir. Ancak, bu da\u011f\u0131t\u0131m\u0131n canl\u0131 ortama yap\u0131l\u0131p yap\u0131lmayaca\u011f\u0131na dair son karar bir insan taraf\u0131ndan verilir. Bu, ekiplere manuel bir onay ad\u0131m\u0131 sunarak, belirli ko\u015fullar alt\u0131nda da\u011f\u0131t\u0131m\u0131 kontrol etme esnekli\u011fi sa\u011flar. \u00d6te yandan, S\u00fcrekli Da\u011f\u0131t\u0131m (Continuous Deployment), S\u00fcrekli Teslimat’\u0131n bir ad\u0131m \u00f6tesidir. E\u011fer t\u00fcm otomatik testler ba\u015far\u0131yla ge\u00e7erse, kod de\u011fi\u015fiklikleri herhangi bir insan m\u00fcdahalesi olmadan do\u011frudan \u00fcretime da\u011f\u0131t\u0131l\u0131r. Bu, yaz\u0131l\u0131m\u0131 m\u00fcmk\u00fcn olan en h\u0131zl\u0131 \u015fekilde kullan\u0131c\u0131lara ula\u015ft\u0131rmay\u0131 hedefler ve manuel hatalar\u0131 tamamen ortadan kald\u0131r\u0131r. Ancak bu model, \u00e7ok g\u00fc\u00e7l\u00fc bir test altyap\u0131s\u0131 ve y\u00fcksek bir otomasyon seviyesi gerektirir. Her iki CD yakla\u015f\u0131m\u0131 da, yaz\u0131l\u0131m\u0131n daha s\u0131k ve daha g\u00fcvenilir bir \u015fekilde piyasaya s\u00fcr\u00fclmesine olanak tan\u0131r, m\u00fc\u015fteri geri bildirimlerinin daha h\u0131zl\u0131 al\u0131nmas\u0131n\u0131 sa\u011flar ve genel olarak geli\u015ftirme s\u00fcrecini h\u0131zland\u0131r\u0131r. \u00d6zetle, CI\/CD, yaz\u0131l\u0131m geli\u015ftirmede h\u0131z, kalite ve verimlili\u011fi art\u0131rmak i\u00e7in vazge\u00e7ilmez bir metodolojidir. Otomatikle\u015ftirilmi\u015f s\u00fcre\u00e7ler sayesinde, ekipler kod yazmaya ve yenilik\u00e7i \u00e7\u00f6z\u00fcmler \u00fcretmeye odaklanabilir, manuel ve tekrarlayan g\u00f6revlerin y\u00fck\u00fcnden kurtulabilirler. Bu da, \u00fcr\u00fcnlerin pazara daha h\u0131zl\u0131 s\u00fcr\u00fclmesi, daha az hata i\u00e7ermesi ve m\u00fc\u015fteri memnuniyetinin artmas\u0131 anlam\u0131na gelir. CI\/CD’nin temel felsefesi, hatalar\u0131 erken bulmak, entegrasyonu kolayla\u015ft\u0131rmak ve yaz\u0131l\u0131m\u0131 s\u00fcrekli olarak da\u011f\u0131t\u0131ma haz\u0131r tutmakt\u0131r. Bu sayede, karma\u015f\u0131k projeler bile daha y\u00f6netilebilir hale gelir ve geli\u015ftiriciler, kodlar\u0131n\u0131n canl\u0131 ortamlarda nas\u0131l performans g\u00f6sterdi\u011fini daha h\u0131zl\u0131 bir \u015fekilde anlayabilirler.<\/p>\n
GitHub Actions, GitHub ekosistemine derinlemesine entegre edilmi\u015f, geli\u015ftiricilere do\u011frudan repolar\u0131 i\u00e7inde otomasyon ve CI\/CD yetenekleri sunan g\u00fc\u00e7l\u00fc bir platformdur. GitHub’da bar\u0131nd\u0131r\u0131lan projeler i\u00e7in do\u011fal bir tercih olmas\u0131n\u0131n yan\u0131 s\u0131ra, basitli\u011fi, geni\u015fleyen pazar yeri ve topluluk deste\u011fi ile h\u0131zla pop\u00fclerlik kazanm\u0131\u015ft\u0131r. Peki, GitHub Actions tam olarak nas\u0131l \u00e7al\u0131\u015f\u0131r ve hangi \u00f6zellikleriyle \u00f6ne \u00e7\u0131kar?<\/p>\n
Temel olarak, GitHub Actions, i\u015f ak\u0131\u015flar\u0131 (workflows) ad\u0131 verilen YAML dosyalar\u0131 arac\u0131l\u0131\u011f\u0131yla tan\u0131mlan\u0131r. Bu i\u015f ak\u0131\u015flar\u0131, deponuzdaki belirli olaylara (\u00f6rne\u011fin, bir push, pull request olu\u015fturulmas\u0131, belirli bir etiketin eklenmesi veya zamanlanm\u0131\u015f bir tetikleyici) tepki verecek \u015fekilde yap\u0131land\u0131r\u0131l\u0131r. Bir i\u015f ak\u0131\u015f\u0131 tetiklendi\u011finde, bir veya daha fazla i\u015f (job) \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Her i\u015f, sanal makinelerde (runner) \u00e7al\u0131\u015ft\u0131r\u0131lan ad\u0131mlardan (steps) olu\u015fur. Bu ad\u0131mlar, komut sat\u0131r\u0131 betikleri olabilece\u011fi gibi, \u00f6nceden tan\u0131mlanm\u0131\u015f “eylemleri” (actions) de kullanabilir. Eylemler, genellikle topluluk veya GitHub taraf\u0131ndan olu\u015fturulmu\u015f, belirli bir g\u00f6revi (\u00f6rne\u011fin, Node.js kurmak, kod linting yapmak, bir Docker imaj\u0131 olu\u015fturmak) ger\u00e7ekle\u015ftiren yeniden kullan\u0131labilir betiklerdir. GitHub Marketplace, binlerce haz\u0131r eylemle doludur ve bu da geli\u015ftiricilerin karma\u015f\u0131k CI\/CD boru hatlar\u0131n\u0131 h\u0131zl\u0131ca olu\u015fturmas\u0131na olanak tan\u0131r. \u00d6rne\u011fin, bir depoya yeni bir commit itildi\u011finde otomatik testleri \u00e7al\u0131\u015ft\u0131rmak veya bir web uygulamas\u0131n\u0131 bulut sa\u011flay\u0131c\u0131s\u0131na da\u011f\u0131tmak gibi senaryolar\u0131 kolayca kurgulayabilirsiniz.<\/p>\n
GitHub Actions’\u0131n en b\u00fcy\u00fck avantajlar\u0131ndan biri, GitHub’\u0131n kendisiyle olan s\u0131k\u0131 entegrasyonudur. Kodunuz, pull request’leriniz ve CI\/CD boru hatlar\u0131n\u0131z tek bir platformda bulunur, bu da geli\u015ftirme s\u00fcrecini sadele\u015ftirir. Ayr\u0131ca, platformun sundu\u011fu bar\u0131nd\u0131r\u0131lan “runner”lar sayesinde, kendi altyap\u0131n\u0131z\u0131 kurma veya y\u00f6netme y\u00fck\u00fcnden kurtulursunuz. Linux, Windows ve macOS \u00fczerinde \u00e7al\u0131\u015fan runner’lar sayesinde \u00e7e\u015fitli ortamlar i\u00e7in test ve da\u011f\u0131t\u0131m yapabilirsiniz. Ancak, daha fazla kontrol veya \u00f6zel donan\u0131m gerektiren durumlar i\u00e7in kendi kendine bar\u0131nd\u0131r\u0131lan (self-hosted) runner’lar\u0131 da kullanma se\u00e7ene\u011finiz mevcuttur. Gizli anahtarlar ve API anahtarlar\u0131 gibi hassas bilgileri g\u00fcvenli bir \u015fekilde y\u00f6netmek i\u00e7in GitHub Secrets \u00f6zelli\u011fi kullan\u0131l\u0131r. Bu s\u0131rlar, i\u015f ak\u0131\u015flar\u0131n\u0131zda do\u011frudan kullan\u0131labilir ancak loglarda veya \u00e7\u0131kt\u0131larda asla g\u00f6r\u00fcnmezler, bu da g\u00fcvenlik a\u00e7\u0131s\u0131ndan kritik bir unsurdur.<\/p>\n
A\u015fa\u011f\u0131da basit bir GitHub Actions i\u015f ak\u0131\u015f\u0131 \u00f6rne\u011fi bulunmaktad\u0131r. Bu \u00f6rnek, bir repoya her push yap\u0131ld\u0131\u011f\u0131nda Node.js uygulamas\u0131n\u0131n testlerini \u00e7al\u0131\u015ft\u0131r\u0131r:<\/p>\n
\nname: Node.js CI\n\non:\n push:\n branches: [ \"main\" ]\n pull_request:\n branches: [ \"main\" ]\n\njobs:\n build:\n runs-on: ubuntu-latest\n\n strategy:\n matrix:\n node-version: [14.x, 16.x, 18.x]\n\n steps:\n - uses: actions\/checkout@v3\n - name: Use Node.js ${{ matrix.node-version }}\n uses: actions\/setup-node@v3\n with:\n node-version: ${{ matrix.node-version }}\n cache: 'npm'\n - run: npm ci\n - run: npm test\n<\/pre>\n<\/code><\/p>\n
Bu YAML dosyas\u0131, ana dala yap\u0131lan push'larda veya ana dala a\u00e7\u0131lan pull request'lerde tetiklenen bir \"build\" i\u015fi tan\u0131mlar. \u0130\u015f, Ubuntu \u00fczerinde \u00e7al\u0131\u015f\u0131r ve Node.js'nin farkl\u0131 s\u00fcr\u00fcmlerinde (14, 16, 18) testleri paralel olarak \u00e7al\u0131\u015ft\u0131r\u0131r. Her bir ad\u0131mda, ilgili eylemler (checkout, setup-node) kullan\u0131l\u0131r ve ard\u0131ndan NPM ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fcklenir (npm ci<\/code>) ve testler \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r (npm test<\/code>). Bu yap\u0131, GitHub Actions'\u0131n esnekli\u011fini ve g\u00fc\u00e7l\u00fc entegrasyon yeteneklerini net bir \u015fekilde ortaya koyar.<\/p>\nGitLab CI'\u0131n Derinlikleri: Nas\u0131l Bir S\u00fcre\u00e7 Sunar?<\/h3>\n
GitLab CI, GitLab'\u0131n tam entegre bir par\u00e7as\u0131 olarak, kaynak kontrol\u00fcnden proje y\u00f6netimine, g\u00fcvenlik taramas\u0131ndan CI\/CD'ye kadar t\u00fcm DevOps ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc tek bir platformda birle\u015ftirmeyi hedefler. GitLab'\u0131n temel de\u011fer \u00f6nerisi olan \"tek bir uygulama\" felsefesi, CI\/CD yeteneklerini de kapsaml\u0131 bir \u015fekilde kapsar ve kullan\u0131c\u0131lara ba\u015ftan sona tutarl\u0131 bir deneyim sunar. Peki, GitLab CI'\u0131n derinlikleri nelerdir ve onu di\u011ferlerinden ay\u0131ran \u00f6zellikler hangileridir?<\/p>\n
GitLab CI'\u0131n kalbinde, her projenin k\u00f6k dizininde bulunan ve .gitlab-ci.yml<\/code> ad\u0131ndaki YAML dosyas\u0131 yer al\u0131r. Bu dosya, projenizin CI\/CD boru hatt\u0131n\u0131 tan\u0131mlar. GitHub Actions'ta oldu\u011fu gibi, bu dosya da olaylara (push, merge request, tag olu\u015fturma vb.) tepki veren i\u015fleri (jobs) ve a\u015famalar\u0131 (stages) yap\u0131land\u0131r\u0131r. GitLab CI'da i\u015f ak\u0131\u015f\u0131, belirli a\u015famalara (build, test, deploy gibi) ayr\u0131l\u0131r ve bu a\u015famalar s\u0131ras\u0131yla \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Her a\u015fama i\u00e7inde, paralel olarak \u00e7al\u0131\u015fabilen birden fazla i\u015f tan\u0131mlanabilir. Bu yap\u0131, karma\u015f\u0131k boru hatlar\u0131n\u0131 d\u00fczenli ve okunabilir bir \u015fekilde organize etmeye yard\u0131mc\u0131 olur.<\/p>\nGitLab CI, \"Runner\" ad\u0131 verilen ajanlar \u00fczerinde \u00e7al\u0131\u015f\u0131r. Bu runner'lar, GitLab taraf\u0131ndan y\u00f6netilen payla\u015f\u0131ml\u0131 runner'lar olabilece\u011fi gibi, kendi altyap\u0131n\u0131zda bar\u0131nd\u0131rd\u0131\u011f\u0131n\u0131z \u00f6zel runner'lar da olabilir. Kendi kendine bar\u0131nd\u0131r\u0131lan runner'lar, \u00f6zel donan\u0131m gereksinimleri olan projeler veya y\u00fcksek g\u00fcvenlikli ortamlarda \u00e7al\u0131\u015fan \u015firketler i\u00e7in idealdir. Ayr\u0131ca, GitLab Runner'lar Docker konteynerlerini destekleyerek, her i\u015fin izole ve tutarl\u0131 bir ortamda \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Bu \"Docker in Docker\" (DinD) yetene\u011fi, \u00f6zellikle Docker imajlar\u0131 olu\u015fturma veya karma\u015f\u0131k konteyner tabanl\u0131 uygulamalar\u0131 test etme s\u00fcre\u00e7lerinde b\u00fcy\u00fck esneklik sunar.<\/p>\n
GitLab CI'\u0131n dikkat \u00e7ekici bir di\u011fer \u00f6zelli\u011fi de kapsaml\u0131 entegrasyonlar\u0131d\u0131r. G\u00fcvenlik taramalar\u0131 (SAST, DAST, Container Scanning), ba\u011f\u0131ml\u0131l\u0131k taramalar\u0131, lisans uyumlulu\u011fu kontrol\u00fc ve performans testleri gibi bir\u00e7ok DevOps arac\u0131 do\u011frudan boru hatt\u0131na entegre edilebilir. Bu sayede, g\u00fcvenlik ve kalite kontrolleri geli\u015ftirme s\u00fcrecinin erken a\u015famalar\u0131na ta\u015f\u0131n\u0131r (shift-left security). Ayr\u0131ca, GitLab'\u0131n kendi konteyner kay\u0131t defteri (Container Registry) ve paket kay\u0131t defteri (Package Registry) gibi yerle\u015fik \u00f6zellikleri, da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini daha da kolayla\u015ft\u0131r\u0131r. Secret'lar ve de\u011fi\u015fkenler, projenin ayarlar\u0131nda g\u00fcvenli bir \u015fekilde saklan\u0131r ve YAML dosyalar\u0131nda referans g\u00f6sterilerek kullan\u0131l\u0131r, bu da hassas verilerin korunmas\u0131na yard\u0131mc\u0131 olur.<\/p>\n
Uzman \u0130pucu: GitLab CI'da only<\/code>\/except<\/code> anahtar kelimelerini kullanarak i\u015flerin belirli dallarda, etiketlerde veya merge request'lerde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayarak pipeline'lar\u0131n\u0131z\u0131 daha dinamik ve kaynak dostu hale getirebilirsiniz. Bu, \u00f6zellikle monorepolarda veya \u00f6zel da\u011f\u0131t\u0131m senaryolar\u0131nda \u00e7ok i\u015fe yarar.<\/div>\nA\u015fa\u011f\u0131da basit bir GitLab CI .gitlab-ci.yml<\/code> dosyas\u0131 \u00f6rne\u011fi bulunmaktad\u0131r. Bu \u00f6rnek, bir Node.js projesinin testlerini \u00e7al\u0131\u015ft\u0131r\u0131r ve ard\u0131ndan bir da\u011f\u0131t\u0131m a\u015famas\u0131 i\u00e7erir:<\/p>\n\nstages:\n - build\n - test\n - deploy\n\nbuild_job:\n stage: build\n image: node:18-alpine\n script:\n - echo \"Building the application...\"\n - npm install\n\ntest_job:\n stage: test\n image: node:18-alpine\n script:\n - echo \"Running tests...\"\n - npm test\n dependencies:\n - build_job\n\ndeploy_job:\n stage: deploy\n image: alpine\/git\n script:\n - echo \"Deploying to production...\"\n # Da\u011f\u0131t\u0131m komutlar\u0131 buraya gelir, \u00f6rne\u011fin:\n # - ssh user@yourserver \"cd \/app && git pull && npm install && pm2 restart app\"\n only:\n - main\n needs:\n - test_job\n<\/pre>\n<\/code><\/p>\n
Bu YAML dosyas\u0131, \u00fc\u00e7 a\u015famadan (build, test, deploy) olu\u015fan bir boru hatt\u0131 tan\u0131mlar. build_job<\/code> a\u015famas\u0131nda ba\u011f\u0131ml\u0131l\u0131klar y\u00fcklenir, test_job<\/code> a\u015famas\u0131nda testler \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r ve deploy_job<\/code> a\u015famas\u0131nda ise sadece main<\/code> dal\u0131na yap\u0131lan push'larda tetiklenen bir da\u011f\u0131t\u0131m i\u015flemi ger\u00e7ekle\u015ftirilir. dependencies<\/code> ve needs<\/code> anahtar kelimeleri, i\u015fler aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131 ve \u00e7al\u0131\u015fma s\u0131ralar\u0131n\u0131 a\u00e7\u0131k\u00e7a belirtir. Bu yap\u0131, GitLab CI'\u0131n esnekli\u011fini, a\u015famal\u0131 \u00e7al\u0131\u015fma prensibini ve entegre \u00f6zelliklerini g\u00f6stermektedir.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131nda GitHub Actions vs GitLab CI: Hangi Ara\u00e7 Nereye Daha Uygun?<\/h2>\n
CI\/CD ara\u00e7lar\u0131n\u0131n teknik \u00f6zelliklerini incelemek bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r, ancak as\u0131l \u00f6nemli olan, bu ara\u00e7lar\u0131n ger\u00e7ek d\u00fcnya projelerinde nas\u0131l performans g\u00f6sterdi\u011fi ve belirli senaryolara ne kadar iyi uyum sa\u011flad\u0131\u011f\u0131d\u0131r. Her projenin kendine \u00f6zg\u00fc gereksinimleri, ekip yap\u0131s\u0131 ve k\u00fclt\u00fcr\u00fc vard\u0131r; bu da \"en iyi\" arac\u0131n olmad\u0131\u011f\u0131n\u0131, yaln\u0131zca \"en uygun\" arac\u0131n oldu\u011funu g\u00f6sterir. \u015eimdi, farkl\u0131 senaryolar \u00fczerinden GitHub Actions ve GitLab CI'\u0131n hangi durumlarda parlad\u0131\u011f\u0131n\u0131 inceleyelim.<\/p>\n
Vaka Analizi 1: A\u00e7\u0131k Kaynak Projeler ve Bireysel Geli\u015ftiriciler<\/h3>\n
K\u00fc\u00e7\u00fck veya orta \u00f6l\u00e7ekli a\u00e7\u0131k kaynak projeler, ki\u015fisel portf\u00f6y projeleri veya bireysel geli\u015ftiriciler genellikle basitli\u011fe, h\u0131zl\u0131 ba\u015flang\u0131ca ve maliyet etkinli\u011fine \u00f6ncelik verirler. Bu senaryoda, GitHub Actions genellikle do\u011fal bir lider olarak \u00f6ne \u00e7\u0131kar. Neden mi? \u00c7\u00fcnk\u00fc \u00e7o\u011fu a\u00e7\u0131k kaynak projesi zaten GitHub \u00fczerinde bar\u0131nd\u0131r\u0131lmaktad\u0131r. Bu da GitHub Actions'\u0131n projenin kaynak kodu ile s\u0131f\u0131r entegrasyon \u00e7abas\u0131yla an\u0131nda \u00e7al\u0131\u015fmaya ba\u015flayabilece\u011fi anlam\u0131na gelir. GitHub'\u0131n \u00fccretsiz katman\u0131, a\u00e7\u0131k kaynak projeleri i\u00e7in olduk\u00e7a c\u00f6mert CI\/CD dakikalar\u0131 ve depolama alan\u0131 sunar, bu da maliyet endi\u015felerini ortadan kald\u0131r\u0131r. GitHub Marketplace'deki haz\u0131r eylemlerin bollu\u011fu, geli\u015ftiricilerin h\u0131zl\u0131ca karma\u015f\u0131k g\u00f6revleri otomatikle\u015ftirmesine olanak tan\u0131r. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131n deploy edilmesi, dok\u00fcmantasyonun g\u00fcncellenmesi veya yeni bir s\u00fcr\u00fcm\u00fcn yay\u0131nlanmas\u0131 gibi i\u015flemler, birka\u00e7 sat\u0131r YAML kodu ve mevcut eylemlerle kolayca ger\u00e7ekle\u015ftirilebilir. Ayr\u0131ca, GitHub'\u0131n geni\u015f ve aktif toplulu\u011fu sayesinde, kar\u015f\u0131la\u015f\u0131lan sorunlara h\u0131zl\u0131ca \u00e7\u00f6z\u00fcm bulmak veya yeni eylemler ke\u015ffetmek olduk\u00e7a kolayd\u0131r. Bir geli\u015ftirici, React tabanl\u0131 ki\u015fisel blog projesini her commit'te otomatik olarak Vercel'e da\u011f\u0131tmak istedi\u011finde, GitHub Actions ile sadece birka\u00e7 dakika i\u00e7inde bir i\u015f ak\u0131\u015f\u0131 olu\u015fturabilir. Bu senaryoda GitLab CI da kullan\u0131labilir, ancak projenin GitLab'a ta\u015f\u0131nmas\u0131 veya ayr\u0131 bir entegrasyon ad\u0131m\u0131 gerektirmesi, GitHub ekosisteminde kalmak isteyen geli\u015ftiriciler i\u00e7in ek bir maliyet anlam\u0131na gelecektir. Bu nedenle, GitHub ekosistemine derinden ba\u011fl\u0131 olan, h\u0131zl\u0131 prototipleme ve d\u00fc\u015f\u00fck maliyet arayan a\u00e7\u0131k kaynak projeler ve bireysel geli\u015ftiriciler i\u00e7in GitHub Actions genellikle daha cazip bir se\u00e7enektir.<\/p>\n
Vaka Analizi 2: B\u00fcy\u00fck Kurumsal Yap\u0131lar ve Kendi Kendine Bar\u0131nd\u0131rma Gereksinimleri<\/h3>\n
B\u00fcy\u00fck kurumsal yap\u0131lar, \u00f6zellikle finans, sa\u011fl\u0131k veya savunma gibi d\u00fczenlemeye tabi sekt\u00f6rlerde faaliyet g\u00f6sterenler, genellikle g\u00fcvenlik, uyumluluk, veri egemenli\u011fi ve \u00f6zel altyap\u0131 gereksinimleri gibi konularda \u00e7ok daha s\u0131k\u0131 protokollere sahiptir. Bu t\u00fcr senaryolarda, GitLab CI'\u0131n kapsaml\u0131 ve entegre yap\u0131s\u0131 genellikle daha a\u011f\u0131r basar. Birincisi, GitLab, self-hosted (kendi kendine bar\u0131nd\u0131r\u0131lan) bir \u00e7\u00f6z\u00fcm olarak tamamen kurumsal sunuculara kurulabilir. Bu, t\u00fcm kaynak kodunun, CI\/CD boru hatlar\u0131n\u0131n ve \u00fcretilen yap\u0131lar\u0131n (artifacts) \u015firketin kendi kontrol\u00fcnde kalmas\u0131n\u0131 sa\u011flar, bu da veri egemenli\u011fi ve g\u00fcvenlik endi\u015felerini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde giderir. Hassas verilerin bulut sa\u011flay\u0131c\u0131lar\u0131na g\u00f6nderilmesi ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r. \u0130kincisi, GitLab'\u0131n \"tek bir uygulama\" felsefesi, proje y\u00f6netiminden g\u00fcvenlik taramalar\u0131na, konteyner kay\u0131t defterinden CI\/CD'ye kadar t\u00fcm DevOps ara\u00e7lar\u0131n\u0131 tek bir aray\u00fczde birle\u015ftirir. Bu entegrasyon, karma\u015f\u0131k kurumsal ortamlarda ara\u00e7 zinciri karma\u015fas\u0131n\u0131 azalt\u0131r ve y\u00f6netimi kolayla\u015ft\u0131r\u0131r. \u00d6rne\u011fin, bir banka, kendi veri merkezinde ko\u015fan bir sistem \u00fczerinde hassas m\u00fc\u015fteri verileriyle \u00e7al\u0131\u015fan bir uygulama geli\u015ftiriyor olabilir. Bu durumda, t\u00fcm CI\/CD s\u00fcre\u00e7lerinin \u015firket i\u00e7i sunucularda \u00e7al\u0131\u015fmas\u0131, \u00f6zel g\u00fcvenlik kontrollerinin uygulanabilmesi ve denetim izlerinin kolayca sa\u011flanabilmesi kritik \u00f6nem ta\u015f\u0131r. GitLab CI'\u0131n esnek runner mimarisi, bu t\u00fcr ortamlarda \u00f6zel donan\u0131mlar veya yal\u0131t\u0131lm\u0131\u015f a\u011f segmentleri \u00fczerinde runner'lar \u00e7al\u0131\u015ft\u0131rmas\u0131na olanak tan\u0131r. GitHub Actions da self-hosted runner'lar\u0131 desteklese de, GitLab'\u0131n tam entegre \u00e7\u00f6z\u00fcm\u00fc, \u00f6zellikle g\u00fcvenlik ve uyumluluk konular\u0131nda daha b\u00fct\u00fcnsel bir yakla\u015f\u0131m sunar. Sonu\u00e7 olarak, y\u00fcksek g\u00fcvenlik gereksinimleri olan, kendi altyap\u0131lar\u0131n\u0131 y\u00f6netmek isteyen ve t\u00fcm DevOps ara\u00e7lar\u0131n\u0131 tek bir platformda birle\u015ftirmeyi arayan b\u00fcy\u00fck kurumsal m\u00fc\u015fteriler i\u00e7in GitLab CI, GitHub Actions'a g\u00f6re daha avantajl\u0131 bir se\u00e7enek sunar.<\/p>\n
Teknik Farkl\u0131l\u0131klar ve Karar Verme Kriterleri: Performans, Esneklik ve G\u00fcvenlik<\/h2>\n
GitHub Actions ve GitLab CI aras\u0131ndaki tercihte, sadece kullan\u0131m kolayl\u0131\u011f\u0131 veya pop\u00fclerlik de\u011fil, ayn\u0131 zamanda temel teknik farkl\u0131l\u0131klar ve bu farkl\u0131l\u0131klar\u0131n projenizin performans, esneklik ve g\u00fcvenlik gereksinimleri \u00fczerindeki etkileri de b\u00fcy\u00fck rol oynar. Her iki platform da g\u00fc\u00e7l\u00fc CI\/CD yetenekleri sunsa da, altta yatan mimarileri ve sunduklar\u0131 ara\u00e7lar aras\u0131nda belirgin ayr\u0131mlar bulunur.<\/p>\n
Runner Mimarisi ve Performans<\/h3>\n
Her iki platform da hem payla\u015f\u0131ml\u0131 (hosted) hem de kendi kendine bar\u0131nd\u0131r\u0131lan (self-hosted) runner'lar\u0131 destekler. GitHub Actions, Ubuntu, Windows ve macOS i\u00e7in bar\u0131nd\u0131r\u0131lan runner'lar sunarken, GitLab CI da benzer bir \u00e7e\u015fitlilik sa\u011flar. Ancak, \u00f6zellikle performans ve \u00f6zelle\u015ftirme a\u00e7\u0131s\u0131ndan baz\u0131 farkl\u0131l\u0131klar g\u00f6ze \u00e7arpar. GitHub Actions'ta, her i\u015f (job) genellikle s\u0131f\u0131rdan olu\u015fturulan bir sanal makinede \u00e7al\u0131\u015f\u0131r ve i\u015f bitti\u011finde bu makine yok edilir. Bu, i\u015fler aras\u0131nda izolasyon sa\u011flar ancak ba\u015flang\u0131\u00e7 (startup) s\u00fcrelerine ek y\u00fck getirebilir. GitLab CI'da ise runner'lar genellikle Docker konteynerleri i\u00e7inde \u00e7al\u0131\u015f\u0131r, bu da daha h\u0131zl\u0131 ba\u015flang\u0131\u00e7 s\u00fcreleri ve daha d\u00fc\u015f\u00fck kaynak t\u00fcketimi anlam\u0131na gelebilir, \u00f6zellikle ayn\u0131 runner \u00fczerinde birden fazla i\u015f art arda \u00e7al\u0131\u015f\u0131yorsa. GitLab'\u0131n dind<\/code> (Docker-in-Docker) yetene\u011fi, CI\/CD boru hatt\u0131 i\u00e7inde Docker imajlar\u0131 olu\u015fturmak ve test etmek isteyen projeler i\u00e7in olduk\u00e7a g\u00fc\u00e7l\u00fc ve entegre bir \u00e7\u00f6z\u00fcm sunar. Caching mekanizmalar\u0131 her iki platformda da mevcuttur ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n her seferinde yeniden indirilmesini engelleyerek build s\u00fcrelerini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r. GitHub Actions'\u0131n actions\/cache<\/code> eylemi, olduk\u00e7a esnek ve g\u00fc\u00e7l\u00fcd\u00fcr. GitLab CI'da ise cache<\/code> anahtar kelimesi ile benzer i\u015flevsellik sa\u011flan\u0131r. Performans a\u00e7\u0131s\u0131ndan, b\u00fcy\u00fck ve karma\u015f\u0131k projelerde kendi kendine bar\u0131nd\u0131r\u0131lan runner'lar kullanmak, her iki platformda da daha iyi kontrol ve potansiyel olarak daha y\u00fcksek performans sa\u011flayabilir. Kurumsal ortamlar i\u00e7in, GitLab'\u0131n runner y\u00f6netimindeki esnekli\u011fi ve kendi i\u00e7inde Docker konteynerleri ile daha iyi entegrasyonu bazen bir avantaj sa\u011flayabilirken, GitHub Actions'\u0131n modern ve minimalist tasar\u0131m\u0131 daha k\u00fc\u00e7\u00fck projelerde h\u0131zl\u0131 ba\u015flang\u0131\u00e7 imkan\u0131 sunar.<\/p>\nEsneklik ve Geni\u015fletilebilirlik<\/h3>\n
Esneklik, CI\/CD ara\u00e7lar\u0131 se\u00e7iminde \u00f6nemli bir kriterdir. GitHub Actions, \"marketplace\" ad\u0131 verilen devasa bir eylem k\u00fct\u00fcphanesi ile geni\u015fletilebilirli\u011fini sa\u011flar. Geli\u015ftiriciler, haz\u0131r eylemleri kolayca kullanabilir veya kendi eylemlerini olu\u015fturup toplulukla payla\u015fabilirler. Bu, \u00f6zellikle yayg\u0131n g\u00f6revler i\u00e7in h\u0131zl\u0131 \u00e7\u00f6z\u00fcmler bulmay\u0131 kolayla\u015ft\u0131r\u0131r. GitLab CI ise, do\u011frudan YAML dosyas\u0131nda komut sat\u0131r\u0131 betikleri yazma esnekli\u011fi sunman\u0131n yan\u0131 s\u0131ra, \u015fablonlar (templates) ve include mekanizmalar\u0131 ile boru hatlar\u0131n\u0131 yeniden kullan\u0131labilir hale getirme imkan\u0131 tan\u0131r. Bu, \u00f6zellikle b\u00fcy\u00fck kurulu\u015flarda standart boru hatlar\u0131 olu\u015fturmak ve bunlar\u0131 birden fazla projede uygulamak i\u00e7in kullan\u0131\u015fl\u0131d\u0131r. Ayr\u0131ca, her iki platform da matrix build'lar\u0131 destekler; bu da farkl\u0131 kombinasyonlarda (\u00f6rne\u011fin, farkl\u0131 Node.js versiyonlar\u0131 ve i\u015fletim sistemleri) paralel testler yapmay\u0131 m\u00fcmk\u00fcn k\u0131lar. Artifact (yap\u0131) y\u00f6netimi de \u00f6nemli bir esneklik g\u00f6stergesidir. Her iki ara\u00e7 da derlenmi\u015f kodlar\u0131, test raporlar\u0131n\u0131 veya di\u011fer \u00e7\u0131kt\u0131lar\u0131 saklamak i\u00e7in artifact'leri destekler. Ancak GitLab'\u0131n yerle\u015fik konteyner kay\u0131t defteri ve paket kay\u0131t defteri, \u00f6zellikle DevOps s\u00fcre\u00e7lerinin t\u00fcm\u00fcn\u00fc tek bir platformda tutmak isteyenler i\u00e7in ek bir entegrasyon kolayl\u0131\u011f\u0131 sunar. GitHub Actions'ta ise, artifact'ler genellikle depolama i\u00e7in kullan\u0131l\u0131rken, da\u011f\u0131t\u0131m i\u00e7in harici hizmetlerle (AWS S3, Docker Hub vb.) entegrasyon gereklidir.<\/p>\n
G\u00fcvenlik ve S\u0131rlar Y\u00f6netimi<\/h3>\n
CI\/CD boru hatlar\u0131nda g\u00fcvenlik, en kritik konulardan biridir. API anahtarlar\u0131, veritaban\u0131 \u015fifreleri ve di\u011fer hassas bilgiler asla do\u011frudan YAML dosyalar\u0131na yaz\u0131lmamal\u0131d\u0131r. Her iki platform da bu t\u00fcr s\u0131rlar i\u00e7in g\u00fcvenli mekanizmalar sunar. GitHub Actions, \"Secrets\" ad\u0131 verilen bir \u00f6zellik ile hassas verileri \u015fifreli olarak depolar ve i\u015f ak\u0131\u015flar\u0131nda g\u00fcvenli bir \u015fekilde kullan\u0131lmas\u0131n\u0131 sa\u011flar. Bu s\u0131rlar, loglarda veya \u00e7\u0131kt\u0131 \u00fczerinde asla g\u00f6r\u00fcnmez. GitLab CI da benzer \u015fekilde, proje veya grup d\u00fczeyinde \"CI\/CD Variables\" ad\u0131 alt\u0131nda s\u0131rlar ve de\u011fi\u015fkenler tan\u0131mlama imkan\u0131 sunar. Bu de\u011fi\u015fkenler de \u015fifrelenir ve boru hatt\u0131nda g\u00fcvenli bir \u015fekilde kullan\u0131l\u0131r. Her iki platformda da bu s\u0131rlar i\u00e7in eri\u015fim kontrol\u00fc ve denetim izleri mevcuttur. Ancak, b\u00fcy\u00fck kurulu\u015flar i\u00e7in kendi kendine bar\u0131nd\u0131rma se\u00e7ene\u011fi, g\u00fcvenlik politikalar\u0131n\u0131 tam olarak uygulama ve hassas verilerin \u015firket s\u0131n\u0131rlar\u0131 i\u00e7inde kalmas\u0131n\u0131 sa\u011flama a\u00e7\u0131s\u0131ndan kritik bir avantajd\u0131r. GitLab'\u0131n yerle\u015fik g\u00fcvenlik tarama ara\u00e7lar\u0131 (SAST, DAST, ba\u011f\u0131ml\u0131l\u0131k taramas\u0131 vb.) boru hatt\u0131n\u0131n bir par\u00e7as\u0131 olarak otomatikle\u015ftirilebilir, bu da geli\u015ftirme s\u00fcrecinin erken a\u015famalar\u0131nda g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n tespit edilmesine yard\u0131mc\u0131 olur. GitHub Actions da benzer g\u00fcvenlik eylemleri sunsa da, GitLab'\u0131n \"tek uygulama\" modelindeki entegrasyon derinli\u011fi bazen daha kapsaml\u0131 bir g\u00fcvenlik duru\u015fu sa\u011flayabilir. Sonu\u00e7 olarak, her iki platform da g\u00fcvenli CI\/CD s\u00fcre\u00e7leri i\u00e7in temel gereksinimleri kar\u015f\u0131lar. Ancak, projenizin \u00f6zel g\u00fcvenlik gereksinimleri, reg\u00fclasyonlara uyum ihtiyac\u0131 ve kendi kendine bar\u0131nd\u0131rma tercihi, hangi platformun size daha uygun oldu\u011funa karar vermede belirleyici fakt\u00f6rler olacakt\u0131r.<\/p>\n
\n\n\n\u00d6zellik<\/th>\n GitHub Actions<\/th>\n GitLab CI<\/th>\n<\/tr>\n<\/thead>\n \n\nEntegrasyon<\/b><\/td>\n GitHub ekosistemine tam entegre. Geni\u015f 3. parti entegrasyonlar.<\/td>\n T\u00fcm GitLab DevOps ya\u015fam d\u00f6ng\u00fcs\u00fc ile tam entegre.<\/td>\n<\/tr>\n \nYap\u0131land\u0131rma<\/b><\/td>\n .github\/workflows\/*.yml<\/code> dosyalar\u0131.<\/td>\n.gitlab-ci.yml<\/code> dosyas\u0131.<\/td>\n<\/tr>\n\nYeniden Kullan\u0131m<\/b><\/td>\n Marketplace'deki haz\u0131r eylemler, kompozit eylemler.<\/td>\n Templates, include<\/code> anahtar kelimesi, CI\/CD bile\u015fenleri.<\/td>\n<\/tr>\n\nRunner'lar<\/b><\/td>\n GitHub taraf\u0131ndan bar\u0131nd\u0131r\u0131lan (Ubuntu, Windows, macOS) ve self-hosted runner'lar.<\/td>\n GitLab taraf\u0131ndan bar\u0131nd\u0131r\u0131lan ve self-hosted runner'lar (Docker, Shell, SSH vb. destekler).<\/td>\n<\/tr>\n \nKonteyner Deste\u011fi<\/b><\/td>\n Docker eylemleri ile desteklenir.<\/td>\n Runner'lar genellikle Docker i\u00e7inde \u00e7al\u0131\u015f\u0131r, Docker-in-Docker (DinD) yetene\u011fi g\u00fc\u00e7l\u00fcd\u00fcr.<\/td>\n<\/tr>\n \nS\u0131rlar Y\u00f6netimi<\/b><\/td>\n GitHub Secrets.<\/td>\n CI\/CD Variables (proje\/grup seviyesinde).<\/td>\n<\/tr>\n \nG\u00fcvenlik Taramas\u0131<\/b><\/td>\n 3. parti entegrasyonlar veya Marketplace eylemleri ile (CodeQL gibi).<\/td>\n Dahili SAST, DAST, Dependency Scanning, License Compliance.<\/td>\n<\/tr>\n \nMaliyet Modeli<\/b><\/td>\n A\u00e7\u0131k kaynak projeler i\u00e7in \u00fccretsiz, \u00f6zel depolar i\u00e7in dakika bazl\u0131 \u00fccretlendirme.<\/td>\n Herkese a\u00e7\u0131k projeler i\u00e7in \u00fccretsiz, \u00f6zel projeler i\u00e7in katmanl\u0131 lisanslama.<\/td>\n<\/tr>\n \n\u00d6\u011frenme E\u011frisi<\/b><\/td>\n Genellikle h\u0131zl\u0131 ba\u015flang\u0131\u00e7, geni\u015f dok\u00fcmantasyon ve topluluk.<\/td>\n Kapsaml\u0131 \u00f6zellikler nedeniyle ba\u015flang\u0131\u00e7ta biraz daha dik olabilir.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\u0130leri D\u00fczey Kullan\u0131m \u0130pu\u00e7lar\u0131 ve Optimizasyon Teknikleri: Daha Verimli CI\/CD Ak\u0131\u015flar\u0131<\/h2>\n
CI\/CD ara\u00e7lar\u0131n\u0131 sadece temel g\u00f6revler i\u00e7in kullanmak, potansiyellerinin sadece k\u00fc\u00e7\u00fck bir k\u0131sm\u0131n\u0131 kullanmak demektir. Hem GitHub Actions hem de GitLab CI, daha verimli, \u00f6l\u00e7eklenebilir ve maliyet etkin boru hatlar\u0131 olu\u015fturmak i\u00e7in geli\u015fmi\u015f \u00f6zellikler ve optimizasyon teknikleri sunar. Bu b\u00f6l\u00fcmde, deneyimli kullan\u0131c\u0131lar\u0131n i\u015f ak\u0131\u015flar\u0131n\u0131 bir sonraki seviyeye ta\u015f\u0131yabilecekleri baz\u0131 ipu\u00e7lar\u0131na ve p\u00fcf noktalar\u0131na de\u011finece\u011fiz.<\/p>\n
Custom Runner'lar ve Monorepo Stratejileri<\/h3>\n
\u00d6zellikle b\u00fcy\u00fck ekipler veya \u00f6zel donan\u0131m gereksinimleri olan projeler i\u00e7in kendi kendine bar\u0131nd\u0131r\u0131lan (self-hosted) runner'lar vazge\u00e7ilmezdir. Bu runner'lar, \u00f6zel ba\u011f\u0131ml\u0131l\u0131klar\u0131 \u00f6nceden y\u00fckleyebilir, belirli a\u011f yap\u0131land\u0131rmalar\u0131na eri\u015febilir veya daha g\u00fc\u00e7l\u00fc donan\u0131m kaynaklar\u0131n\u0131 kullanabilir. Hem GitHub Actions hem de GitLab CI, bu t\u00fcr runner'lar\u0131 kolayca kurma ve y\u00f6netme imkan\u0131 sunar. \u00d6rne\u011fin, GPU h\u0131zland\u0131rmal\u0131 testler veya b\u00fcy\u00fck veri setleriyle \u00e7al\u0131\u015fan ML modelleri i\u00e7in \u00f6zel bir runner kurabilirsiniz. Monorepo'lar (birden fazla projenin tek bir depoda tutuldu\u011fu yap\u0131lar) g\u00fcn\u00fcm\u00fczde olduk\u00e7a pop\u00fclerdir. Ancak, monorepolarda her kod de\u011fi\u015fikli\u011finde t\u00fcm projelerin CI\/CD boru hatt\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rmak zaman ve kaynak israf\u0131na neden olabilir. Bu durumu optimize etmek i\u00e7in, sadece de\u011fi\u015ftirilen projenin veya ilgili ba\u011f\u0131ml\u0131l\u0131klar\u0131n test ve da\u011f\u0131t\u0131m\u0131n\u0131n tetiklendi\u011fi ak\u0131ll\u0131 boru hatlar\u0131 olu\u015fturmak m\u00fcmk\u00fcnd\u00fcr. GitHub Actions'ta, paths<\/code> filtresi veya harici bir \"changed files\" eylemi kullanarak belirli dosyalar\u0131n veya klas\u00f6rlerin de\u011fi\u015fmesi durumunda i\u015fleri \u00e7al\u0131\u015ft\u0131rmak olduk\u00e7a yayg\u0131nd\u0131r. GitLab CI'da ise, rules:changes<\/code> veya only:changes<\/code> gibi anahtar kelimelerle benzer bir mant\u0131k uygulanabilir. Bu, boru hatt\u0131 s\u00fcrelerini k\u0131salt\u0131r ve gereksiz kaynak t\u00fcketimini \u00f6nler.<\/p>\nDinamik \u0130\u015f Ak\u0131\u015flar\u0131 ve Maliyet Optimizasyonu<\/h3>\n
Baz\u0131 durumlarda, bir i\u015f ak\u0131\u015f\u0131n\u0131n \u00e7\u0131kt\u0131s\u0131na veya belirli ko\u015fullara g\u00f6re dinamik olarak farkl\u0131 ad\u0131mlar veya i\u015fler \u00e7al\u0131\u015ft\u0131rmak isteyebilirsiniz. GitHub Actions'ta, \u00e7\u0131kt\u0131lar (outputs) ve ko\u015fullu ifadeler (if<\/code>) kullanarak olduk\u00e7a dinamik boru hatlar\u0131 olu\u015fturulabilir. \u00d6rne\u011fin, bir ad\u0131m\u0131n ba\u015far\u0131yla tamamlan\u0131p tamamlanmad\u0131\u011f\u0131na ba\u011fl\u0131 olarak bir sonraki ad\u0131m\u0131 tetikleyebilirsiniz. GitLab CI'da ise, rules<\/code> ve allow_failure<\/code> gibi anahtar kelimelerle daha karma\u015f\u0131k ko\u015fullu mant\u0131klar uygulanabilir. Ayr\u0131ca, needs<\/code> anahtar kelimesi ile i\u015fler aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131 daha net tan\u0131mlayarak paralel y\u00fcr\u00fctmeyi art\u0131rabilirsiniz. Maliyet optimizasyonu, \u00f6zellikle bulut tabanl\u0131 CI\/CD hizmetlerinde \u00f6nemli bir fakt\u00f6rd\u00fcr. Hem GitHub Actions hem de GitLab CI, \u00fccretsiz kullan\u0131m limitleri sunsa da, b\u00fcy\u00fck projelerde bu limitler h\u0131zla a\u015f\u0131labilir. Maliyetleri d\u00fc\u015f\u00fcrmek i\u00e7in yap\u0131labilecekler: \u00f6ncelikle, gereksiz i\u015fleri \u00e7al\u0131\u015ft\u0131rmaktan ka\u00e7\u0131nmak i\u00e7in yukar\u0131da bahsedilen \"monorepo stratejileri\" ve \"dinamik i\u015f ak\u0131\u015flar\u0131\" kullan\u0131labilir. \u0130kincisi, caching stratejilerini optimize etmek, ba\u011f\u0131ml\u0131l\u0131klar\u0131n her seferinde yeniden indirilmesini engelleyerek hem zaman hem de maliyet tasarrufu sa\u011flar. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, self-hosted runner'lar\u0131 kullanmak, baz\u0131 durumlarda bar\u0131nd\u0131r\u0131lan runner'lara k\u0131yasla daha uygun maliyetli olabilir, \u00f6zellikle y\u00fcksek hacimli veya uzun s\u00fcren i\u015fler i\u00e7in. Son olarak, i\u015f ak\u0131\u015f\u0131 loglar\u0131n\u0131 ve artifact'leri d\u00fczenli olarak temizlemek, depolama maliyetlerini d\u00fc\u015f\u00fcrmeye yard\u0131mc\u0131 olur.<\/p>\nDaha \u0130yi Kullan\u0131c\u0131 Deneyimi i\u00e7in Mobil Uyumlu HTML\/CSS \u00d6rnekleri<\/h3>\n
Web uygulamalar\u0131n\u0131n CI\/CD s\u00fcre\u00e7lerinde, kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) ve kullan\u0131c\u0131 deneyimi (UX) testleri de kritik \u00f6neme sahiptir. Modern web uygulamalar\u0131, farkl\u0131 cihazlarda (mobil, tablet, masa\u00fcst\u00fc) sorunsuz \u00e7al\u0131\u015fmal\u0131d\u0131r. CI\/CD boru hatt\u0131n\u0131za otomatik UI testleri (\u00f6rne\u011fin, Cypress, Playwright) ekleyerek, bu uyumlulu\u011fu her de\u011fi\u015fiklikte do\u011frulayabilirsiniz. Mobil uyumlu HTML\/CSS, bu testlerin ve genel web uygulaman\u0131z\u0131n kalitesini do\u011frudan etkiler. A\u015fa\u011f\u0131da basit bir mobil uyumlu CSS medya sorgusu \u00f6rne\u011fi verilmi\u015ftir. Bu, CI\/CD s\u00fcrecinde test edilebilir bir \u00f6rnektir:<\/p>\n
\n