Modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda h\u0131z, kalite ve g\u00fcvenilirlik, rekabet avantaj\u0131 sa\u011flaman\u0131n temel ta\u015flar\u0131 haline gelmi\u015ftir. Peki, bir yaz\u0131l\u0131m projesini geli\u015ftirme a\u015famas\u0131ndan son kullan\u0131c\u0131ya ula\u015ft\u0131rma s\u00fcrecini nas\u0131l h\u0131zland\u0131rabilir, hatalar\u0131 minimuma indirebilir ve s\u00fcrekli olarak de\u011fer sunabiliriz? \u0130\u015fte bu noktada CI\/CD devreye giriyor. Bu kapsaml\u0131 rehberde, CI\/CD’nin ne oldu\u011funu, neden bu kadar \u00f6nemli oldu\u011funu ve ger\u00e7ek bir senaryo \u00fczerinden ad\u0131m ad\u0131m nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ke\u015ffedece\u011fiz. E\u011fer yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinizi optimize etmek ve daha verimli hale getirmek istiyorsan\u0131z, do\u011fru yerdesiniz.<\/p>\n
Yaz\u0131l\u0131m d\u00fcnyas\u0131 s\u00fcrekli bir de\u011fi\u015fim ve geli\u015fim i\u00e7inde. Ge\u00e7mi\u015fte, yaz\u0131l\u0131m projeleri genellikle “\u015felale modeli” (waterfall model) gibi geleneksel yakla\u015f\u0131mlarla y\u00f6netilirdi. Bu modellerde, planlama, tasar\u0131m, geli\u015ftirme, test etme ve da\u011f\u0131t\u0131m gibi a\u015famalar ard\u0131\u015f\u0131k olarak ilerlerdi. Bir a\u015fama bitmeden di\u011ferine ge\u00e7ilmezdi ve bu durum, \u00f6zellikle b\u00fcy\u00fck projelerde uzun geli\u015ftirme d\u00f6ng\u00fclerine, ge\u00e7 teslimlere ve son dakika hatalar\u0131na yol a\u00e7abiliyordu. M\u00fc\u015fteri geri bildirimleri genellikle projenin sonlar\u0131na do\u011fru al\u0131nd\u0131\u011f\u0131 i\u00e7in, de\u011fi\u015fiklik yapmak hem zor hem de maliyetli oluyordu. Bu durum, yaz\u0131l\u0131m\u0131n pazara sunulma s\u00fcresini (time-to-market) uzat\u0131yor ve i\u015f d\u00fcnyas\u0131n\u0131n h\u0131z\u0131na ayak uydurmay\u0131 zorla\u015ft\u0131r\u0131yordu.<\/p>\n
Zamanla, daha \u00e7evik (agile) metodolojiler ortaya \u00e7\u0131kt\u0131. \u00c7evik yakla\u015f\u0131mlar, k\u0131sa geli\u015ftirme d\u00f6ng\u00fcleri (sprintler), s\u00fcrekli geri bildirim ve adaptasyona odaklanarak bu sorunlar\u0131n \u00fcstesinden gelmeye \u00e7al\u0131\u015ft\u0131. Ancak \u00e7evik olman\u0131n tek ba\u015f\u0131na yeterli olmad\u0131\u011f\u0131 anla\u015f\u0131ld\u0131. Geli\u015ftiriciler kodlar\u0131n\u0131 s\u0131k s\u0131k birle\u015ftirdiklerinde (integrate), bu birle\u015fimler genellikle “birle\u015fim cehennemi” (integration hell) olarak adland\u0131r\u0131lan karma\u015f\u0131k ve hataya a\u00e7\u0131k durumlar yaratabiliyordu. Farkl\u0131 geli\u015ftiricilerin ayn\u0131 anda farkl\u0131 \u00f6zellikler \u00fczerinde \u00e7al\u0131\u015fmas\u0131, kod \u00e7ak\u0131\u015fmalar\u0131na, uyumluluk sorunlar\u0131na ve uzun hata ay\u0131klama s\u00fcre\u00e7lerine neden oluyordu. Her yeni \u00f6zellik veya hata d\u00fczeltmesi, manuel test ve da\u011f\u0131t\u0131m s\u00fcre\u00e7leri nedeniyle yine de \u00f6nemli bir zaman alabiliyordu. \u0130\u015fte bu noktada, yaz\u0131l\u0131m geli\u015ftirme ve teslimat s\u00fcre\u00e7lerini otomatikle\u015ftirme ihtiyac\u0131 do\u011fdu. CI\/CD, tam da bu ihtiyaca cevap veren, yaz\u0131l\u0131m\u0131n daha h\u0131zl\u0131, daha g\u00fcvenilir ve daha s\u0131k bir \u015fekilde m\u00fc\u015fteriye ula\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flayan bir dizi ilke ve uygulama b\u00fct\u00fcn\u00fcd\u00fcr. Bu sayede, yaz\u0131l\u0131m geli\u015ftirme ekipleri, s\u00fcrekli entegrasyon (Continuous Integration), s\u00fcrekli teslimat (Continuous Delivery) ve s\u00fcrekli da\u011f\u0131t\u0131m (Continuous Deployment) pratiklerini benimseyerek, modern i\u015f d\u00fcnyas\u0131n\u0131n beklentilerini kar\u015f\u0131layabilecek \u00e7evikli\u011fi ve h\u0131z\u0131 yakalayabilirler.<\/p>\n
CI\/CD, asl\u0131nda iki ana b\u00f6l\u00fcmden olu\u015fan bir s\u00fcre\u00e7ler b\u00fct\u00fcn\u00fcd\u00fcr: S\u00fcrekli Entegrasyon (Continuous Integration – CI) ve S\u00fcrekli Teslimat (Continuous Delivery – CD) veya S\u00fcrekli Da\u011f\u0131t\u0131m (Continuous Deployment – CD). Bu iki kavram, modern yaz\u0131l\u0131m geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fcn temelini olu\u015fturur ve birlikte kullan\u0131ld\u0131\u011f\u0131nda b\u00fcy\u00fck bir sinerji yarat\u0131r.<\/p>\n
S\u00fcrekli Entegrasyon (CI), geli\u015ftiricilerin kod de\u011fi\u015fikliklerini merkezi bir depoya (\u00f6rne\u011fin Git tabanl\u0131 bir sistem) d\u00fczenli ve s\u0131k aral\u0131klarla birle\u015ftirmeleri (merge) prati\u011fidir. Geleneksel yakla\u015f\u0131mlarda, geli\u015ftiriciler uzun s\u00fcreler boyunca kendi kodlar\u0131 \u00fczerinde \u00e7al\u0131\u015f\u0131r ve sonra t\u00fcm de\u011fi\u015fiklikleri bir kerede birle\u015ftirmeye \u00e7al\u0131\u015f\u0131rlard\u0131. Bu durum, b\u00fcy\u00fck kod \u00e7ak\u0131\u015fmalar\u0131na ve birle\u015fme hatalar\u0131na yol a\u00e7arak “birle\u015fim cehennemi” ya\u015fanmas\u0131na neden olurdu. CI, bu sorunlar\u0131 ortadan kald\u0131rmay\u0131 hedefler. Geli\u015ftiriciler, genellikle g\u00fcnde birka\u00e7 kez, hatta her k\u00fc\u00e7\u00fck de\u011fi\u015fiklikten sonra kodlar\u0131n\u0131 ana dala (main branch) g\u00f6nderirler (push).<\/p>\n
Her kod g\u00f6nderimi (push) veya birle\u015ftirme (merge) i\u015fleminden sonra, otomatik bir sistem devreye girer. Bu sistem, yeni eklenen kodu mevcut kod taban\u0131yla birle\u015ftirir, projeyi derler (build eder) ve bir dizi otomatik test (birim testleri, entegrasyon testleri vb.) \u00e7al\u0131\u015ft\u0131r\u0131r. Bu testler, yeni kodun mevcut i\u015flevselli\u011fi bozup bozmad\u0131\u011f\u0131n\u0131 veya yeni hatalar i\u00e7erip i\u00e7ermedi\u011fini kontrol eder. E\u011fer derleme veya test a\u015famalar\u0131ndan herhangi biri ba\u015far\u0131s\u0131z olursa, ekip an\u0131nda bilgilendirilir. Bu sayede hatalar, geli\u015ftirme s\u00fcrecinin \u00e7ok erken a\u015famalar\u0131nda tespit edilir ve d\u00fczeltilir. Erken tespit edilen hatalar, hem d\u00fczeltilmesi daha kolay hem de daha az maliyetlidir. CI’\u0131n temel amac\u0131, kod taban\u0131n\u0131n her zaman \u00e7al\u0131\u015f\u0131r durumda ve kararl\u0131 kalmas\u0131n\u0131 sa\u011flamakt\u0131r. Bu pratik, geli\u015ftiricilerin g\u00fcvenle kod yazmas\u0131na olanak tan\u0131r ve entegrasyon kaynakl\u0131 sorunlar\u0131n \u00f6n\u00fcne ge\u00e7er.<\/p>\n
S\u00fcrekli Teslimat (CD), CI s\u00fcrecini bir ad\u0131m \u00f6teye ta\u015f\u0131yarak, kodun ba\u015far\u0131l\u0131 bir \u015fekilde derlenip test edildikten sonra, her zaman da\u011f\u0131t\u0131ma haz\u0131r bir durumda olmas\u0131n\u0131 sa\u011flar. Yani, her ba\u015far\u0131l\u0131 CI d\u00f6ng\u00fcs\u00fcn\u00fcn ard\u0131ndan, yaz\u0131l\u0131m bir test veya haz\u0131rl\u0131k (staging) ortam\u0131na otomatik olarak da\u011f\u0131t\u0131labilir hale gelir. Bu a\u015famada, insan m\u00fcdahalesi olmadan, tek bir tu\u015fa basarak veya basit bir komutla yaz\u0131l\u0131m\u0131n canl\u0131 (production) ortama ge\u00e7irilmesi m\u00fcmk\u00fcnd\u00fcr. S\u00fcrekli Teslimat, yaz\u0131l\u0131m\u0131n manuel onay gerektiren son da\u011f\u0131t\u0131m ad\u0131m\u0131 hari\u00e7 t\u00fcm s\u00fcre\u00e7lerini otomatikle\u015ftirir. Bu, \u00fcr\u00fcn y\u00f6neticilerinin veya operasyon ekiplerinin, istedikleri zaman, g\u00fcvenle yeni bir s\u00fcr\u00fcm\u00fc canl\u0131ya alabilmelerine olanak tan\u0131r. B\u00f6ylece, yeni \u00f6zellikler ve hata d\u00fczeltmeleri \u00e7ok daha h\u0131zl\u0131 bir \u015fekilde son kullan\u0131c\u0131lara ula\u015ft\u0131r\u0131labilir.<\/p>\n
S\u00fcrekli Da\u011f\u0131t\u0131m (CD) ise, S\u00fcrekli Teslimat’\u0131n tam otomatize edilmi\u015f halidir. Bu modelde, CI ve CD s\u00fcre\u00e7leri ba\u015far\u0131yla tamamland\u0131ktan sonra, herhangi bir insan m\u00fcdahalesi veya onay\u0131 olmaks\u0131z\u0131n, yaz\u0131l\u0131m otomatik olarak canl\u0131 (production) ortama da\u011f\u0131t\u0131l\u0131r. Yani, bir geli\u015ftirici kodunu ana dala g\u00f6nderir, bu kod ba\u015far\u0131l\u0131 bir \u015fekilde derlenir, t\u00fcm testleri ge\u00e7er ve ard\u0131ndan do\u011frudan son kullan\u0131c\u0131n\u0131n eri\u015febilece\u011fi ortama da\u011f\u0131t\u0131l\u0131r. S\u00fcrekli Da\u011f\u0131t\u0131m, yaz\u0131l\u0131m teslimat\u0131n\u0131 en \u00fcst d\u00fczeyde h\u0131zland\u0131r\u0131r ve pazara sunma s\u00fcresini (time-to-market) \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r. Ancak bu yakla\u015f\u0131m, \u00e7ok y\u00fcksek otomasyon, kapsaml\u0131 test kapsam\u0131 ve g\u00fc\u00e7l\u00fc izleme (monitoring) sistemleri gerektirir. Herhangi bir hata durumunda h\u0131zl\u0131 geri alma (rollback) yetene\u011fi de kritik \u00f6neme sahiptir. Genellikle, y\u00fcksek g\u00fcvene sahip ve olgunla\u015fm\u0131\u015f ekipler taraf\u0131ndan tercih edilen bir yakla\u015f\u0131md\u0131r. Her iki CD yakla\u015f\u0131m\u0131 da, yaz\u0131l\u0131m\u0131n de\u011ferini m\u00fc\u015fteriye daha h\u0131zl\u0131 ve daha g\u00fcvenilir bir \u015fekilde ula\u015ft\u0131rmay\u0131 hedeflerken, S\u00fcrekli Da\u011f\u0131t\u0131m bu s\u00fcreci tamamen otomatikle\u015ftirerek insan fakt\u00f6r\u00fcn\u00fc ortadan kald\u0131r\u0131r.<\/p>\n
CI\/CD pratikleri, g\u00fcn\u00fcm\u00fcz rekabet\u00e7i i\u015f d\u00fcnyas\u0131nda yaz\u0131l\u0131m geli\u015ftiren her kurulu\u015f i\u00e7in adeta bir zorunluluk haline gelmi\u015ftir. Bu sistemlerin sundu\u011fu avantajlar, sadece teknik ekipleri de\u011fil, t\u00fcm i\u015f birimlerini ve son kullan\u0131c\u0131lar\u0131 da olumlu y\u00f6nde etkiler. Peki, CI\/CD’yi bu kadar vazge\u00e7ilmez k\u0131lan temel nedenler nelerdir?<\/p>\n
\u00d6zetle, CI\/CD sadece bir otomasyon arac\u0131 de\u011fil, ayn\u0131 zamanda modern yaz\u0131l\u0131m geli\u015ftirme felsefesinin temel bir bile\u015fenidir. Yaz\u0131l\u0131m\u0131n kalitesini, teslimat h\u0131z\u0131n\u0131 ve ekip verimlili\u011fini art\u0131rarak, i\u015fletmelerin dijital d\u00f6n\u00fc\u015f\u00fcm yolculu\u011funda ba\u015far\u0131l\u0131 olmalar\u0131 i\u00e7in kritik bir rol oynar.<\/p>\n
Bir CI\/CD hatt\u0131 (pipeline), yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecinin her a\u015famas\u0131n\u0131 otomatikle\u015ftiren bir dizi ad\u0131mdan olu\u015fur. Bu ad\u0131mlar, kodun yaz\u0131lmas\u0131ndan ba\u015flay\u0131p, test edilip, son kullan\u0131c\u0131ya da\u011f\u0131t\u0131lmas\u0131na kadar uzan\u0131r. Her a\u015fama, bir \u00f6nceki a\u015faman\u0131n ba\u015far\u0131l\u0131 bir \u015fekilde tamamlanmas\u0131na ba\u011fl\u0131d\u0131r. \u0130\u015fte tipik bir CI\/CD hatt\u0131n\u0131n temel a\u015famalar\u0131 ve nas\u0131l \u00e7al\u0131\u015ft\u0131klar\u0131:<\/p>\n
Her \u015fey, geli\u015ftiricinin kodunu bir s\u00fcr\u00fcm kontrol sistemine (Version Control System – VCS) g\u00f6ndermesiyle ba\u015flar. Genellikle Git tabanl\u0131 sistemler (GitHub, GitLab, Bitbucket, Azure DevOps Repos) kullan\u0131l\u0131r. Geli\u015ftiriciler, \u00f6zellik dallar\u0131nda (feature branches) \u00e7al\u0131\u015f\u0131r ve tamamlad\u0131klar\u0131nda bu de\u011fi\u015fiklikleri ana dala (main\/master branch) birle\u015ftirme iste\u011fi (pull request\/merge request) a\u00e7arlar. CI\/CD hatt\u0131, bu t\u00fcr bir birle\u015ftirme iste\u011fi veya do\u011frudan ana dala yap\u0131lan bir g\u00f6nderim (push) tetiklendi\u011finde otomatik olarak ba\u015flar.<\/p>\n
Kod ba\u015far\u0131yla s\u00fcr\u00fcm kontrol sistemine g\u00f6nderildikten sonra, CI\/CD hatt\u0131n\u0131n ilk otomatik ad\u0131m\u0131 derleme (build) a\u015famas\u0131d\u0131r. Bu a\u015famada, yaz\u0131lan kaynak kodu \u00e7al\u0131\u015ft\u0131r\u0131labilir bir formata d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. Bu, bir Java projesi i\u00e7in JAR\/WAR dosyas\u0131 olu\u015fturmak, bir .NET projesi i\u00e7in DLL\/EXE derlemek, bir Node.js projesi i\u00e7in ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fcklemek ( Derleme ba\u015far\u0131l\u0131 olduktan sonra, yaz\u0131l\u0131m\u0131n do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak i\u00e7in otomatik testler devreye girer. Bu, CI\/CD hatt\u0131n\u0131n en kritik a\u015famalar\u0131ndan biridir ve farkl\u0131 test t\u00fcrlerini i\u00e7erebilir:<\/p>\n T\u00fcm bu testler otomatik olarak \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Herhangi bir testin ba\u015far\u0131s\u0131z olmas\u0131 durumunda, pipeline durdurulur ve geli\u015ftiricilere hata raporu g\u00f6nderilir. Bu, hatal\u0131 kodun bir sonraki a\u015famaya ge\u00e7mesini engeller.<\/p>\n Testler ba\u015far\u0131yla tamamland\u0131ktan sonra, yaz\u0131l\u0131m\u0131n da\u011f\u0131t\u0131ma haz\u0131r oldu\u011fu anlam\u0131na gelir. S\u00fcrekli Teslimat (Continuous Delivery) modelinde, bu a\u015famada yaz\u0131l\u0131m bir veya daha fazla haz\u0131rl\u0131k (staging) ortam\u0131na otomatik olarak da\u011f\u0131t\u0131l\u0131r. Bu ortamlar, canl\u0131 ortama \u00e7ok benzerdir ve son kontrollerin, manuel testlerin veya \u00fcr\u00fcn y\u00f6neticileri taraf\u0131ndan yap\u0131lan onaylar\u0131n ger\u00e7ekle\u015ftirilmesi i\u00e7in kullan\u0131l\u0131r. Bu a\u015fama genellikle bir insan onay\u0131 gerektirir; yani, yaz\u0131l\u0131m\u0131n canl\u0131 ortama ge\u00e7irilip ge\u00e7irilmeyece\u011fine dair karar manuel olarak verilir.<\/p>\n S\u00fcrekli Da\u011f\u0131t\u0131m (Continuous Deployment) modelinde ise, haz\u0131rl\u0131k ortam\u0131na da\u011f\u0131t\u0131m\u0131n ard\u0131ndan herhangi bir manuel onay olmaks\u0131z\u0131n, yaz\u0131l\u0131m otomatik olarak canl\u0131 (production) ortama da\u011f\u0131t\u0131l\u0131r. Bu, her ba\u015far\u0131l\u0131 kod de\u011fi\u015fikli\u011finin do\u011frudan son kullan\u0131c\u0131lara ula\u015ft\u0131\u011f\u0131 anlam\u0131na gelir. Bu model, y\u00fcksek otomasyon seviyesi, kapsaml\u0131 testler ve g\u00fc\u00e7l\u00fc izleme (monitoring) sistemleri gerektirir, \u00e7\u00fcnk\u00fc herhangi bir sorun durumunda h\u0131zl\u0131 geri alma (rollback) yetene\u011fi kritik \u00f6neme sahiptir. Da\u011f\u0131t\u0131m a\u015famas\u0131, sunuculara kodun kopyalanmas\u0131, kapsay\u0131c\u0131lar\u0131n (Docker) da\u011f\u0131t\u0131lmas\u0131, Kubernetes gibi orkestrasyon ara\u00e7lar\u0131n\u0131n kullan\u0131lmas\u0131 veya sunucusuz (serverless) fonksiyonlar\u0131n g\u00fcncellenmesi gibi \u00e7e\u015fitli y\u00f6ntemlerle ger\u00e7ekle\u015ftirilebilir.<\/p>\n Yaz\u0131l\u0131m canl\u0131 ortama da\u011f\u0131t\u0131ld\u0131ktan sonra CI\/CD hatt\u0131 bitmez. Canl\u0131 ortamdaki uygulaman\u0131n performans\u0131, hatalar\u0131 ve kullan\u0131c\u0131 deneyimi s\u00fcrekli olarak izlenir (monitor edilir). Loglama (logging) ve metrik (metrics) toplama ara\u00e7lar\u0131 kullan\u0131l\u0131r. Herhangi bir sorun tespit edildi\u011finde, ilgili ekiplere (geli\u015ftiriciler, operasyon) otomatik olarak uyar\u0131lar g\u00f6nderilir. Bu geri bildirimler, geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fcn bir sonraki iterasyonunda dikkate al\u0131narak \u00fcr\u00fcn\u00fcn s\u00fcrekli olarak iyile\u015ftirilmesini sa\u011flar. Bu, DevOps k\u00fclt\u00fcr\u00fcn\u00fcn “s\u00fcrekli iyile\u015ftirme” (continuous improvement) ilkesinin \u00f6nemli bir par\u00e7as\u0131d\u0131r.<\/p>\n Bu ad\u0131mlar b\u00fct\u00fcn\u00fc, yaz\u0131l\u0131m\u0131n g\u00fcvenli, h\u0131zl\u0131 ve tutarl\u0131 bir \u015fekilde geli\u015ftirilmesini ve teslim edilmesini sa\u011flar. Her a\u015faman\u0131n otomatize edilmesi, insan hatas\u0131 riskini azalt\u0131r ve ekiplerin daha de\u011ferli i\u015flere odaklanmas\u0131na olanak tan\u0131r.<\/p>\n \u015eimdi, \u00f6\u011frendi\u011fimiz teorik bilgileri ger\u00e7ek d\u00fcnya bir senaryo \u00fczerinden somutla\u015ft\u0131ral\u0131m. Basit bir mikroservis tabanl\u0131 web uygulamas\u0131 i\u00e7in bir CI\/CD pipeline’\u0131 nas\u0131l kuraca\u011f\u0131m\u0131z\u0131 ad\u0131m ad\u0131m inceleyelim. Bu \u00f6rnekte, bir Node.js tabanl\u0131 API servisi ve bir React tabanl\u0131 kullan\u0131c\u0131 aray\u00fcz\u00fc (frontend) uygulamas\u0131 oldu\u011funu varsayal\u0131m. Her iki uygulama da ayr\u0131 Git depolar\u0131nda (repositories) bulunuyor ve Docker konteynerleri (containers) i\u00e7inde \u00e7al\u0131\u015facak, Kubernetes \u00fczerinde da\u011f\u0131t\u0131lacak.<\/p>\n Bu \u00f6rnekte, React frontend uygulamas\u0131n\u0131n GitLab deposuna bir kod de\u011fi\u015fikli\u011fi g\u00f6nderildi\u011finde tetiklenecek bir GitLab CI\/CD pipeline’\u0131n\u0131 ele alaca\u011f\u0131z. Backend i\u00e7in de benzer ad\u0131mlar uygulanacakt\u0131r.<\/p>\n Bir geli\u015ftirici, React uygulamas\u0131nda yeni bir \u00f6zellik ekler veya bir hatay\u0131 d\u00fczeltir. De\u011fi\u015fikliklerini yerel olarak test ettikten sonra, GitLab, bu merge request’in a\u00e7\u0131ld\u0131\u011f\u0131n\u0131 veya ana dala bir kod g\u00f6nderimi yap\u0131ld\u0131\u011f\u0131n\u0131 alg\u0131lar ve otomatik olarak GitLab CI, pipeline’\u0131 \u00e7al\u0131\u015ft\u0131rmak i\u00e7in bir Runner (ko\u015fucu) ba\u015flat\u0131r. Bu Runner, projenin kaynak kodunu \u00e7eker ve a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 ger\u00e7ekle\u015ftirir:<\/p>\n Runner, React projesi i\u00e7in gerekli Node.js ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 y\u00fckler ve uygulaman\u0131n \u00fcretim i\u00e7in derlenmi\u015f (built) statik dosyalar\u0131n\u0131 olu\u015fturur.<\/p>\n Bu ad\u0131mda herhangi bir ba\u011f\u0131ml\u0131l\u0131k hatas\u0131 veya derleme sorunu ya\u015fan\u0131rsa, pipeline ba\u015far\u0131s\u0131z olur ve geli\u015ftiriciye bilgi verilir.<\/p>\n Derleme ba\u015far\u0131l\u0131 olduktan sonra, otomatik testler \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Bu testler, yeni eklenen kodun mevcut i\u015flevselli\u011fi bozmad\u0131\u011f\u0131ndan emin olmak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n E\u011fer herhangi bir test ba\u015far\u0131s\u0131z olursa, pipeline durur ve geli\u015ftiriciye hatan\u0131n nerede oldu\u011fu bildirilir. Bu sayede hatalar, canl\u0131 ortama ula\u015fmadan \u00e7ok \u00f6nce tespit edilir ve d\u00fczeltilir.<\/p>\n T\u00fcm derleme ve test ad\u0131mlar\u0131 ba\u015far\u0131yla ge\u00e7ildikten sonra, uygulama da\u011f\u0131t\u0131ma haz\u0131r hale gelir.<\/p>\n Uygulaman\u0131n derlenmi\u015f statik dosyalar\u0131 (\u00f6nceki a\u015famadan gelen artifact’lar), bir Docker imaj\u0131 i\u00e7ine yerle\u015ftirilir. Bu imaj, uygulaman\u0131n t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 ve \u00e7al\u0131\u015fma zaman\u0131 ortam\u0131n\u0131 i\u00e7erir, b\u00f6ylece her ortamda tutarl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmas\u0131 sa\u011flan\u0131r. Olu\u015fturulan imaj, bir Docker kay\u0131t defterine (Registry – \u00f6rne\u011fin GitLab Container Registry veya Docker Hub) g\u00f6nderilir.<\/p>\n Olu\u015fturulan Docker imaj\u0131, Kubernetes k\u00fcmesindeki haz\u0131rl\u0131k (staging) ortam\u0131na da\u011f\u0131t\u0131l\u0131r. Bu da\u011f\u0131t\u0131m, Kubernetes manifest dosyalar\u0131 (Deployment, Service) kullan\u0131larak yap\u0131l\u0131r.<\/p>\n Bu noktada, \u00fcr\u00fcn y\u00f6neticileri veya QA ekibi, haz\u0131rl\u0131k ortam\u0131ndaki uygulamay\u0131 manuel olarak test edebilir ve canl\u0131ya ge\u00e7i\u015f i\u00e7in onay verebilir.<\/p>\n E\u011fer S\u00fcrekli Da\u011f\u0131t\u0131m kullan\u0131l\u0131yorsa ve haz\u0131rl\u0131k ortam\u0131ndaki testler ba\u015far\u0131l\u0131 bulunursa, uygulama otomatik olarak veya manuel bir onay ad\u0131m\u0131yla canl\u0131 ortama da\u011f\u0131t\u0131l\u0131r. Bu ad\u0131m genellikle en hassas olan\u0131d\u0131r ve manuel onay ad\u0131m\u0131 eklemek, riski azaltmak i\u00e7in yayg\u0131n bir pratiktir.<\/p>\n Canl\u0131ya al\u0131nan uygulama, Prometheus, Grafana, ELK Stack gibi ara\u00e7larla s\u00fcrekli izlenir. Herhangi bir hata veya performans sorunu durumunda, ekiplere otomatik uyar\u0131lar g\u00f6nderilir. Bu geri bildirimler, geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fcn bir sonraki iterasyonunda iyile\u015ftirmeler yapmak i\u00e7in kullan\u0131l\u0131r.<\/p>\n Bu \u00f6rnek, modern bir web uygulamas\u0131n\u0131n CI\/CD pipeline’\u0131n\u0131n nas\u0131l yap\u0131land\u0131r\u0131labilece\u011fine dair temel bir bak\u0131\u015f sunmaktad\u0131r. Her projenin kendine \u00f6zg\u00fc ihtiya\u00e7lar\u0131 olsa da, temel ad\u0131mlar ve prensipler genellikle ayn\u0131 kal\u0131r.<\/p>\n CI\/CD pipeline’\u0131n\u0131 kurmak ve \u00e7al\u0131\u015ft\u0131rmak, modern yaz\u0131l\u0131m geli\u015ftirmenin temel bir par\u00e7as\u0131d\u0131r. Ancak bu s\u00fcreci ger\u00e7ekten optimize etmek ve en iyi verimi almak i\u00e7in baz\u0131 \u00f6nemli noktalara dikkat etmek ve ileri d\u00fczey konular\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmak gerekir.<\/p>\n CI\/CD’nin temel amac\u0131, g\u00fcvenilirli\u011fi art\u0131rmakt\u0131r. Bu g\u00fcvenilirli\u011fin en \u00f6nemli bile\u015feni ise kapsaml\u0131 ve otomatik testlerdir. Sadece birim testleriyle yetinmemek, entegrasyon, fonksiyonel, u\u00e7tan uca (end-to-end – E2E) ve performans testlerini de pipeline’a dahil etmek kritik \u00f6neme sahiptir. Test piramidi yakla\u015f\u0131m\u0131n\u0131 benimseyerek, alt seviye testleri (birim) \u00e7ok say\u0131da ve h\u0131zl\u0131 bir \u015fekilde, \u00fcst seviye testleri (E2E) ise daha az say\u0131da ve yava\u015f bir \u015fekilde \u00e7al\u0131\u015ft\u0131rmak en verimli y\u00f6ntemdir. Unutmay\u0131n, testleriniz ne kadar eksiksiz olursa, otomatik da\u011f\u0131t\u0131ma olan g\u00fcveniniz de o kadar artar.<\/p>\n G\u00fcvenlik, CI\/CD s\u00fcrecinin ayr\u0131lmaz bir par\u00e7as\u0131 olmal\u0131d\u0131r. Geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fcn sonuna b\u0131rak\u0131lan g\u00fcvenlik kontrolleri, maliyetli ve zaman al\u0131c\u0131 hatalara yol a\u00e7abilir. Bunun yerine, “Shift Left” (g\u00fcvenli\u011fi sola kayd\u0131rma) prensibiyle, g\u00fcvenlik taramalar\u0131n\u0131 pipeline’\u0131n erken a\u015famalar\u0131na dahil etmek \u00f6nemlidir:<\/p>\n Bu entegrasyon, DevSecOps k\u00fclt\u00fcr\u00fcn\u00fcn bir par\u00e7as\u0131d\u0131r ve yaz\u0131l\u0131m\u0131n ba\u015ftan sona g\u00fcvenli olmas\u0131n\u0131 sa\u011flar.<\/p>\n En iyi testlere ra\u011fmen, canl\u0131 ortamda beklenmedik sorunlar ortaya \u00e7\u0131kabilir. Bu gibi durumlarda, h\u0131zl\u0131 bir geri alma (rollback) mekanizmas\u0131na sahip olmak hayati \u00f6nem ta\u015f\u0131r. CI\/CD pipeline’\u0131n\u0131z, \u00f6nceki kararl\u0131 s\u00fcr\u00fcme h\u0131zl\u0131ca geri d\u00f6nebilme yetene\u011fine sahip olmal\u0131d\u0131r. Bu genellikle, bir \u00f6nceki ba\u015far\u0131l\u0131 da\u011f\u0131t\u0131m\u0131n Docker imaj\u0131n\u0131 veya uygulama s\u00fcr\u00fcm\u00fcn\u00fc tekrar da\u011f\u0131tarak yap\u0131l\u0131r. Otomatik geri alma se\u00e7enekleri de (\u00f6rne\u011fin, izleme sistemleri belirli bir hata e\u015fi\u011fini a\u015ft\u0131\u011f\u0131nda otomatik geri alma) d\u00fc\u015f\u00fcn\u00fclebilir.<\/p>\n Geli\u015ftirme, test, haz\u0131rl\u0131k (staging) ve canl\u0131 (production) ortamlar\u0131n\u0131n m\u00fcmk\u00fcn oldu\u011funca birbirine benzer olmas\u0131 (parite) \u00f6nemlidir. “Altyap\u0131 Kod Olarak” (Infrastructure as Code – IaC) prensipleri (Terraform, Ansible gibi ara\u00e7larla) kullan\u0131larak ortamlar\u0131n otomatik olarak sa\u011flanmas\u0131 ve yap\u0131land\u0131r\u0131lmas\u0131, ortamlar aras\u0131 farkl\u0131l\u0131klardan kaynaklanan hatalar\u0131 minimize eder. Her ortam i\u00e7in ayn\u0131 da\u011f\u0131t\u0131m mekanizmalar\u0131n\u0131n kullan\u0131lmas\u0131 da tutarl\u0131l\u0131\u011f\u0131 art\u0131r\u0131r.<\/p>\n Docker gibi kapsay\u0131c\u0131 teknolojileri, uygulamalar\u0131n ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131n paketlenmesini standartla\u015ft\u0131rarak “benim makinemde \u00e7al\u0131\u015f\u0131yor” sorununu ortadan kald\u0131r\u0131r. Kubernetes gibi kapsay\u0131c\u0131 orkestrasyon ara\u00e7lar\u0131 ise, bu kapsay\u0131c\u0131lar\u0131n b\u00fcy\u00fck \u00f6l\u00e7ekte y\u00f6netilmesini, da\u011f\u0131t\u0131lmas\u0131n\u0131, \u00f6l\u00e7eklenmesini ve izlenmesini otomatikle\u015ftirir. CI\/CD pipeline’\u0131n\u0131z\u0131n Docker imajlar\u0131 olu\u015fturup bir kay\u0131t defterine g\u00f6ndermesi ve ard\u0131ndan Kubernetes’e da\u011f\u0131tmas\u0131, modern uygulamalar i\u00e7in g\u00fc\u00e7l\u00fc bir kombinasyondur.<\/p>\n Uygulama canl\u0131ya al\u0131nd\u0131ktan sonra, CI\/CD s\u00fcrecinin son ad\u0131m\u0131 izleme ve geri bildirimdir. Prometheus ile metrik toplama, Grafana ile g\u00f6rselle\u015ftirme, ELK Stack (Elasticsearch, Logstash, Kibana) ile log y\u00f6netimi ve PagerDuty gibi ara\u00e7larla uyar\u0131 sistemleri kurmak, uygulaman\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 s\u00fcrekli olarak takip etmenizi sa\u011flar. Anormallikler veya hatalar durumunda otomatik uyar\u0131lar almak, sorunlara h\u0131zl\u0131ca m\u00fcdahale etme ve potansiyel kesintileri \u00f6nleme yetene\u011fi sunar.<\/p>\n Uzun s\u00fcren CI\/CD pipeline’lar\u0131, geli\u015ftirici verimlili\u011fini d\u00fc\u015f\u00fcrebilir. Pipeline’\u0131 h\u0131zland\u0131rmak i\u00e7in:<\/p>\n Bu ileri d\u00fczey konular ve dikkat edilmesi gereken noktalar, CI\/CD yat\u0131r\u0131m\u0131n\u0131zdan maksimum fayda sa\u011flaman\u0131za yard\u0131mc\u0131 olacakt\u0131r. S\u00fcrekli \u00f6\u011frenme ve pipeline’\u0131n\u0131z\u0131 s\u00fcrekli iyile\u015ftirme, bu s\u00fcrecin ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r.<\/p>\n 1. CI\/CD sadece b\u00fcy\u00fck \u015firketler i\u00e7in mi uygundur?<\/strong><\/p>\n Hay\u0131r, CI\/CD pratikleri her boyuttaki yaz\u0131l\u0131m ekibi ve projesi i\u00e7in uygundur. K\u00fc\u00e7\u00fck ekipler ve start-up’lar bile CI\/CD otomasyonundan b\u00fcy\u00fck faydalar sa\u011flayabilir. Erken benimsenmesi, projenin b\u00fcy\u00fcmesiyle birlikte ya\u015fanabilecek karma\u015f\u0131kl\u0131klar\u0131 y\u00f6netmeyi kolayla\u015ft\u0131r\u0131r ve uzun vadede maliyet tasarrufu sa\u011flar.<\/p>\n 2. CI\/CD kurmak ne kadar s\u00fcrer ve ne kadar zordur?<\/strong><\/p>\n CI\/CD kurma s\u00fcresi ve zorlu\u011fu, projenin b\u00fcy\u00fckl\u00fc\u011f\u00fcne, mevcut altyap\u0131ya ve ekibin deneyimine ba\u011fl\u0131d\u0131r. Basit bir proje i\u00e7in temel bir pipeline birka\u00e7 saat i\u00e7inde kurulabilirken, karma\u015f\u0131k mikroservis mimarileri veya \u00f6zel altyap\u0131lar i\u00e7in haftalar s\u00fcrebilir. Ba\u015flang\u0131\u00e7ta temel ad\u0131mlarla ba\u015flamak ve zamanla geli\u015ftirmek en iyi yakla\u015f\u0131md\u0131r. GitLab CI\/CD, GitHub Actions gibi ara\u00e7lar, ba\u015flang\u0131\u00e7 i\u00e7in nispeten kolay entegrasyon sunar.<\/p>\n 3. CI\/CD kullanmak DevOps ile ayn\u0131 \u015fey midir?<\/strong><\/p>\n Hay\u0131r, CI\/CD, DevOps’un bir par\u00e7as\u0131d\u0131r ancak tamam\u0131 de\u011fildir. DevOps, yaz\u0131l\u0131m geli\u015ftirme (Development) ve operasyon (Operations) ekipleri aras\u0131ndaki i\u015fbirli\u011fini, k\u00fclt\u00fcr\u00fc ve ara\u00e7lar\u0131 kapsayan daha geni\u015f bir felsefedir. CI\/CD ise, bu felsefenin otomasyon ve teslimat s\u00fcre\u00e7lerine odaklanan temel pratiklerinden biridir. DevOps, CI\/CD’nin \u00f6tesinde izleme, geri bildirim, altyap\u0131 kod olarak (IaC) gibi bir\u00e7ok ba\u015fka prensibi de i\u00e7erir.<\/p>\n 4. Hangi CI\/CD ara\u00e7lar\u0131n\u0131 kullanmal\u0131y\u0131m?<\/strong><\/p>\n Piyasada bir\u00e7ok pop\u00fcler CI\/CD arac\u0131 bulunmaktad\u0131r. Se\u00e7iminiz projenizin ihtiya\u00e7lar\u0131na, kulland\u0131\u011f\u0131n\u0131z s\u00fcr\u00fcm kontrol sistemine ve b\u00fct\u00e7enize g\u00f6re de\u011fi\u015febilir:<\/p>\n K\u00fc\u00e7\u00fck projeler i\u00e7in genellikle GitLab CI\/CD veya GitHub Actions gibi entegre \u00e7\u00f6z\u00fcmler iyi bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r.<\/p>\n 5. CI\/CD’ye ge\u00e7i\u015f yaparken en b\u00fcy\u00fck zorluklar nelerdir?<\/strong><\/p>\n CI\/CD’ye ge\u00e7i\u015fte kar\u015f\u0131la\u015f\u0131lan ba\u015fl\u0131ca zorluklar \u015funlard\u0131r: Mevcut manuel s\u00fcre\u00e7lerin otomasyona d\u00f6n\u00fc\u015ft\u00fcr\u00fclmesi, yeterli test kapsam\u0131n\u0131n olu\u015fturulmas\u0131, altyap\u0131 ve ortam tutarl\u0131l\u0131\u011f\u0131n\u0131n sa\u011flanmas\u0131, g\u00fcvenlik entegrasyonu ve ekip \u00fcyelerinin yeni ara\u00e7lara ve pratiklere adapte olmas\u0131. Ayr\u0131ca, pipeline’\u0131n s\u00fcrekli izlenmesi ve iyile\u015ftirilmesi de s\u00fcrekli bir \u00e7aba gerektirir. K\u00fclt\u00fcrel de\u011fi\u015fim, bu zorluklar\u0131n \u00fcstesinden gelmede anahtar rol oynar.<\/p>\n CI\/CD, modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131n\u0131n vazge\u00e7ilmez bir par\u00e7as\u0131d\u0131r. Geli\u015ftirme s\u00fcre\u00e7lerini otomatikle\u015ftirerek, kod kalitesini art\u0131r\u0131r, hata oranlar\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcr ve yaz\u0131l\u0131m\u0131n pazara sunulma s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r. S\u00fcrekli Entegrasyon (CI) ile geli\u015ftiricilerin kodlar\u0131n\u0131 s\u0131k s\u0131k birle\u015ftirmesi ve otomatik testlerden ge\u00e7irmesi sa\u011flan\u0131rken, S\u00fcrekli Teslimat\/Da\u011f\u0131t\u0131m (CD) ile yaz\u0131l\u0131m\u0131n g\u00fcvenle ve h\u0131zl\u0131ca canl\u0131 ortama ula\u015ft\u0131r\u0131lmas\u0131 hedeflenir. Bu s\u00fcre\u00e7ler, ekiplerin daha verimli \u00e7al\u0131\u015fmas\u0131na, daha h\u0131zl\u0131 geri bildirim almas\u0131na ve son kullan\u0131c\u0131ya s\u00fcrekli olarak de\u011fer sunmas\u0131na olanak tan\u0131r.<\/p>\n Bir web uygulamas\u0131 \u00f6rne\u011fi \u00fczerinden g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, CI\/CD pipeline’\u0131, kod de\u011fi\u015fikli\u011finden ba\u015flayarak derleme, test, kapsay\u0131c\u0131la\u015ft\u0131rma ve da\u011f\u0131t\u0131m ad\u0131mlar\u0131n\u0131 kapsar. Bu ad\u0131mlar\u0131n her biri, yaz\u0131l\u0131m\u0131n kararl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenilirli\u011fini garanti alt\u0131na almak i\u00e7in otomatize edilir. Ba\u015far\u0131l\u0131 bir CI\/CD uygulamas\u0131, sadece teknik bir otomasyon de\u011fil, ayn\u0131 zamanda kapsaml\u0131 test stratejileri, g\u00fcvenlik entegrasyonu, etkili izleme ve geri alma mekanizmalar\u0131 gibi ileri d\u00fczey konular\u0131 da i\u00e7erir. Unutulmamal\u0131d\u0131r ki, CI\/CD bir kere kurulup b\u0131rak\u0131lacak bir sistem de\u011fil, s\u00fcrekli olarak iyile\u015ftirilmesi ve optimize edilmesi gereken dinamik bir s\u00fcre\u00e7tir. Bu sayede, yaz\u0131l\u0131m geli\u015ftirme ekipleri, de\u011fi\u015fen pazar ko\u015fullar\u0131na h\u0131zla adapte olabilir ve rekabet avantaj\u0131n\u0131 s\u00fcrd\u00fcrebilirler.<\/p>\n #CI\/CD #DevOps #S\u00fcrekliEntegrasyon #S\u00fcrekliTeslimat #Yaz\u0131l\u0131mGeli\u015ftirme #Otomasyon<\/p>\nnpm install<\/code>) ve JavaScript\/CSS dosyalar\u0131n\u0131 s\u0131k\u0131\u015ft\u0131rmak (minify) veya bir Docker imaj\u0131 (image) olu\u015fturmak anlam\u0131na gelebilir. Derleme a\u015famas\u0131nda, gerekli t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar indirilir ve kodun s\u00f6zdizimi (syntax) hatalar\u0131 kontrol edilir. E\u011fer bu a\u015famada bir hata olu\u015fursa (\u00f6rne\u011fin, derleme hatas\u0131 veya eksik ba\u011f\u0131ml\u0131l\u0131k), pipeline durdurulur ve geli\u015ftiriciye geri bildirim sa\u011flan\u0131r.<\/p>\n# \u00d6rnek bir Node.js projesi i\u00e7in derleme ad\u0131mlar\u0131\nnpm install # Ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fckle\nnpm run build # Projeyi derle (\u00f6rne\u011fin React uygulamas\u0131 i\u00e7in)\n<\/code><\/pre>\n<\/div>\n3. Test A\u015famas\u0131<\/h4>\n
\n
# \u00d6rnek bir Node.js projesi i\u00e7in test ad\u0131mlar\u0131\nnpm test # Birim ve entegrasyon testlerini \u00e7al\u0131\u015ft\u0131r\n# Cypress veya Selenium ile u\u00e7tan uca (end-to-end) testleri \u00e7al\u0131\u015ft\u0131r\n<\/code><\/pre>\n<\/div>\n4. Da\u011f\u0131t\u0131m (Deployment) A\u015famas\u0131 – S\u00fcrekli Teslimat<\/h4>\n
5. Da\u011f\u0131t\u0131m (Deployment) A\u015famas\u0131 – S\u00fcrekli Da\u011f\u0131t\u0131m<\/h4>\n
# \u00d6rnek bir Docker ve Kubernetes da\u011f\u0131t\u0131m ad\u0131m\u0131\ndocker build -t my-app:latest . # Docker imaj\u0131 olu\u015ftur\ndocker push my-app:latest # \u0130maj\u0131 Docker Registry'ye g\u00f6nder\nkubectl apply -f kubernetes\/deployment.yaml # Kubernetes'e da\u011f\u0131t\n<\/code><\/pre>\n<\/div>\n6. \u0130zleme (Monitoring) ve Geri Bildirim<\/h4>\n
Ger\u00e7ek Bir CI\/CD Pipeline \u00d6rne\u011fi: Mikroservis Tabanl\u0131 Web Uygulamas\u0131<\/h3>\n
Senaryo Detaylar\u0131:<\/h4>\n
\n
CI\/CD Pipeline Ad\u0131mlar\u0131 (Frontend Uygulamas\u0131 \u0130\u00e7in \u00d6rnek):<\/h4>\n
1. Kod De\u011fi\u015fikli\u011fi ve Tetikleyici (Trigger)<\/h5>\n
feature\/yeni-ozellik<\/code> adl\u0131 bir daldan ana dala (main<\/code>) bir “merge request” (birle\u015ftirme iste\u011fi) a\u00e7ar ve kodu GitLab deposuna g\u00f6nderir (git push<\/code>).<\/p>\n# Geli\u015ftiricinin terminalinde\ngit checkout -b feature\/yeni-ozellik\n# Kod de\u011fi\u015fiklikleri yap\u0131l\u0131r...\ngit add .\ngit commit -m \"Yeni g\u00f6rev ekleme \u00f6zelli\u011fi eklendi\"\ngit push origin feature\/yeni-ozellik\n# GitLab \u00fczerinden merge request olu\u015fturulur.\n<\/code><\/pre>\n<\/div>\n.gitlab-ci.yml<\/code> dosyas\u0131nda tan\u0131mlanan CI\/CD pipeline’\u0131n\u0131 tetikler.<\/p>\n2. CI A\u015famas\u0131: Derleme ve Test<\/h5>\n
a. Ba\u011f\u0131ml\u0131l\u0131klar\u0131 Y\u00fckleme ve Derleme (Build)<\/h6>\n
# .gitlab-ci.yml dosyas\u0131nda ilgili k\u0131s\u0131m\nbuild_job:\n stage: build\n image: node:16 # Node.js 16 imaj\u0131n\u0131 kullan\n script:\n - npm install # Ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fckle\n - npm run build # React uygulamas\u0131n\u0131 derle (dist\/build klas\u00f6r\u00fc olu\u015fur)\n artifacts: # Derlenen dosyalar\u0131 sonraki a\u015famalara aktar\n paths:\n - build\/\n expire_in: 1 day\n<\/code><\/pre>\n<\/div>\nb. Testler<\/h6>\n
# .gitlab-ci.yml dosyas\u0131nda ilgili k\u0131s\u0131m\ntest_job:\n stage: test\n image: node:16\n script:\n - npm install\n - npm test # Birim ve entegrasyon testlerini \u00e7al\u0131\u015ft\u0131r (\u00f6rne\u011fin Jest ile)\n # - npx cypress run # U\u00e7tan uca testler (varsa)\n dependencies:\n - build_job # build_job'dan gelen artifact'lar\u0131 kullan\n<\/code><\/pre>\n<\/div>\n3. CD A\u015famas\u0131: Kapsay\u0131c\u0131la\u015ft\u0131rma ve Da\u011f\u0131t\u0131m<\/h5>\n
a. Docker \u0130maj\u0131 Olu\u015fturma ve Kay\u0131t Defterine G\u00f6nderme<\/h6>\n
# .gitlab-ci.yml dosyas\u0131nda ilgili k\u0131s\u0131m\ndocker_build_push_job:\n stage: deploy\n image: docker:latest # Docker CLI imaj\u0131n\u0131 kullan\n services:\n - docker:dind # Docker in Docker servisini ba\u015flat\n script:\n - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY # GitLab Registry'ye giri\u015f\n - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -t $CI_REGISTRY_IMAGE:latest . # \u0130maj\u0131 olu\u015ftur\n - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA # Belirli commit SHA'l\u0131 imaj\u0131 g\u00f6nder\n - docker push $CI_REGISTRY_IMAGE:latest # latest etiketli imaj\u0131 g\u00f6nder\n dependencies:\n - build_job\n only:\n - main # Sadece main branch'e merge edildi\u011finde \u00e7al\u0131\u015ft\u0131r\n<\/code><\/pre>\n<\/div>\nb. Haz\u0131rl\u0131k (Staging) Ortam\u0131na Da\u011f\u0131t\u0131m (S\u00fcrekli Teslimat)<\/h6>\n
# .gitlab-ci.yml dosyas\u0131nda ilgili k\u0131s\u0131m\ndeploy_staging_job:\n stage: deploy\n image: alpine\/helm:3.8.1 # Helm veya kubectl CLI imaj\u0131\n script:\n - kubectl config use-context <your-kubernetes-context> # Kubernetes ba\u011flam\u0131n\u0131 ayarla\n - kubectl set image deployment\/frontend-app frontend=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n staging # Yeni imajla da\u011f\u0131t\u0131m\u0131 g\u00fcncelle\n environment:\n name: staging\n url: https:\/\/staging.example.com\n when: on_success # \u00d6nceki a\u015famalar ba\u015far\u0131l\u0131 olursa\n only:\n - main\n<\/code><\/pre>\n<\/div>\nc. Canl\u0131 (Production) Ortam\u0131na Da\u011f\u0131t\u0131m (S\u00fcrekli Da\u011f\u0131t\u0131m – \u0130ste\u011fe Ba\u011fl\u0131 Onayl\u0131)<\/h6>\n
# .gitlab-ci.yml dosyas\u0131nda ilgili k\u0131s\u0131m\ndeploy_production_job:\n stage: deploy\n image: alpine\/helm:3.8.1\n script:\n - kubectl config use-context <your-kubernetes-context>\n - kubectl set image deployment\/frontend-app frontend=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n production\n environment:\n name: production\n url: https:\/\/app.example.com\n when: manual # Manuel onay gerektirir\n only:\n - main\n<\/code><\/pre>\n<\/div>\nwhen: manual<\/code> ifadesi, bu ad\u0131m\u0131n sadece bir kullan\u0131c\u0131 taraf\u0131ndan GitLab aray\u00fcz\u00fcnden tetiklenmesiyle \u00e7al\u0131\u015faca\u011f\u0131n\u0131 belirtir. Bu, S\u00fcrekli Teslimat modelinin bir par\u00e7as\u0131d\u0131r ve canl\u0131 da\u011f\u0131t\u0131m \u00fczerinde daha fazla kontrol sa\u011flar.<\/p>\n4. \u0130zleme ve Geri Bildirim<\/h5>\n
CI\/CD Uygulamas\u0131nda Dikkat Edilmesi Gerekenler ve \u0130leri D\u00fczey Konular<\/h3>\n
1. Kapsaml\u0131 Otomatik Testler: CI\/CD’nin Kalbi<\/h4>\n
2. G\u00fcvenlik Entegrasyonu: DevSecOps<\/h4>\n
\n
3. Geri Alma (Rollback) Mekanizmalar\u0131<\/h4>\n
4. Ortam Y\u00f6netimi ve Tutarl\u0131l\u0131k<\/h4>\n
5. Kapsay\u0131c\u0131 Teknolojileri ve Orkestrasyon<\/h4>\n
6. \u0130zleme, Loglama ve Uyar\u0131 Sistemleri<\/h4>\n
7. Pipeline H\u0131z\u0131 ve Optimizasyonu<\/h4>\n
\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n
Sonu\u00e7<\/h3>\n