Ubuntu 20.04 Üzerinde GitLab Sürekli Entegrasyon (CI) Pipeline'ları Nasıl Kurulur

Her geliştirici, sürüm kontrolünün yazılım geliştirme yaşam döngüsü için ne kadar kritik olduğunu anlar. Birden fazla kişinin tek bir proje üzerinde aynı anda çalışmasına, her kişinin kendi kod kopyasını barındırmasına ve bunu ekibin geri kalanıyla ne zaman paylaşacağını seçmesine olanak tanır. Bunu başarmak için geliştiriciler, Git depolarından yararlanırlar. GitLab, bir sürüm kontrol aracından daha fazlası olan web tabanlı bir Git deposudur. Ayrıca DevOps araçları, sorun takibi, sürekli entegrasyon ve dağıtım sağlar.

GitLab seçebileceğiniz üç seçenek sunar: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) ve GitLab SaaS. GitLab CE ve GitLab EE kendi kendine yönetilen çözümlerdir. Bu, GitLab örneğini kendiniz indirip kuracağınız ve yöneteceğiniz anlamına gelir. GitLab SaaS ise GitLab Inc. tarafından barındırılır. Dolayısıyla, kullanmak için herhangi bir şey kurma konusunda endişelenmenize gerek yoktur. Sadece bir GitLab hesabı oluşturmanız ve başlamanız yeterlidir.

Bu eğitimde, depolarınızı değişikliklere karşı izlemek ve yeni kodları doğrulamak üzere otomatik testler çalıştırmak amacıyla GitLab CI ile Sürekli Entegrasyon boru hatlarını nasıl kuracağınızı göstereceğiz. Kodu barındırmak için bir Git deposu kurarak başlayacağız. Ardından, depoya yapılan işlemeleri izlemek için bir CI süreci yapılandıracağız ve testleri izole bir Docker konteynerinde çalıştırmak üzere bir CI çalıştırıcısı başlatacağız.

Gereksinimler

Başlamak için GitLab sürüm kontrol yazılımını çalıştıran bir sunucuya ihtiyacınız olacak. Hem kendi kendine yönetilen GitLab hem de SaaS sürümü otomatik testleri çalıştırabilir. Ancak, ücretsiz SaaS seçeneklerinde testlerinize sunulan süre ve kaynaklar açısından bazı sınırlar vardır. Kendi kendine yönetilen seçenekleri kullanıyorsanız daha fazla özgürlüğe sahip olursunuz çünkü GitLab örneğinize dilediğiniz kadar kaynak ayırabilirsiniz. Kendi GitLab örneğinizi nasıl kuracağınızı öğrenmek için GitLab ile kendi Git Depolarınızı barındırma hakkındaki eğitimimizi takip edin.

GitLab CI çalıştırıcısı olarak kullanmak için en az bir sunucuya ihtiyacınız olacak. Ancak isterseniz daha fazla sunucuya da sahip olabilirsiniz. Kendi kendine yönetilen bir GitLab örneği kurduysanız aynı sunucuyu kullanabilirsiniz, ancak biz CI çalıştırıcısı için farklı bir sunucu ayarlamayı tercih ediyoruz. Ubuntu sunucunuzu nasıl kurarsınız konulu bu eğitim iyi bir başlangıçtır.

Test ortamlarını Docker konteynerlerinde izole etmek için GitLab CI çalıştırıcı sunucularınızda Docker'ın kurulu olması gerekir. Bu gereksinimi tamamlamanıza yardımcı olabilecek Ubuntu üzerinde Docker Nasıl Kurulur ve Çalıştırılır hakkında bir eğitimimiz bulunmaktadır.

İhtiyacımız olan her şeye sahip olduğumuza göre, hadi başlayalım!

Adım 1: Bir GitLab Örneğinde Proje Oluşturma

GitLab üzerinde bir proje deposu oluşturarak başlayacağız. Bu eğitimi bir Node.js uygulaması üzerine kuracağız. Proje dosyalarını sıfırdan oluşturmak istemediğimiz için, GitLab'in sunduğu ve yararlanacağımız diğer sürüm kontrol depolarından projeleri içe aktarma aracını kullanacağız. İçe aktardığımız uygulama, hello world” şeklinde basit bir uygulamadır ve Express.js – Node.js uygulamaları için minimalist bir web çerçevesi ile oluşturulmuştur. Testleri Mocha ve Chai – bunlar birim testi için kullanılan JavaScript çerçeveleridir. Mocha; asenkron test yapmayı, test kapsamı raporları almayı sağlar ve diğer doğrulama kütüphaneleriyle eşleştirilebilir. Chai ise bir doğrulama kütüphanesidir. Herhangi bir test çerçevesiyle eşleştirilebilir; bizim durumumuzda Mocha'yı Chai ile eşleştireceğiz.

Artık projemizin temellerini bildiğinize göre, GitLab örneğinize (ister kendi kendine yönetilen ister SaaS olsun) giriş yapın, üst gezinti çubuğundaki ‘artı’ simgesine tıklayın ve ‘New project’ seçeneğini belirleyin. Alternatif olarak, hesabınızın ana sayfasının üst kısmına kaydırırsanız, ‘New project’ düğmesine tıklayabilirsiniz:

Yeni proje sayfasında, Import project sekmesine tıklayın:

Ardından, açılan sayfada Repo by URL düğmesine tıklayın:

Bir GitHub içe aktarma seçeneği olsa da, Kişisel erişim belirteci gerektirdiği için bunu kullanmayacağız. Herkese açık bir depo ile çalıştığımız için Kişisel erişim belirteçleri ayarlamamıza gerek yoktur ve yalnızca URL ile içe aktarmak oldukça kolaydır.

Bundan sonra, aşağıdaki URL'yi kopyalayın ve Git Repository URL alanına yapıştırın:

Şöyle görünmelidir:

Depoyu Private olarak bırakın ve işiniz bittiğinde Create project butonuna tıklayın. Projenin GitHub'dan içe aktarılması için birkaç saniye bekleyin; proje GitLab depolarınız arasında görünecektir. GitLab, projeyi GitHub deposu projesiyle aynı ayrıntılarla içe aktarır.

Adım 2: .gitlab-ci.yml Dosyasını Analiz Etme

GitLab CI, otomatik testlerin nasıl çalıştırılacağını bilmek için GitLab'daki her depoda .gitlab-ci.yml adında bir dosya arar. Az önce içe aktardığımız depoda, proje dosyaları arasında bir .gitlab-ci.yml dosyası görebilirsiniz. GitLab CI yml hakkında daha fazla bilgiyi resmi Keyword reference for the .gitlab-ci.yml file docs.

GitLab depo arayüzündeyken, tarayıcı sayfasında açmak için .gitlab-ci.yml dosyasına tıklayın. Şöyle görünmelidir:

Satırların girintilerine dikkat edin. Dosya, belirli koşullar altında belirlenmiş bir sırayla gerçekleştirilecek çeşitli eylemleri tanımlamak için katı bir GitLab CI YAML yapılandırma sözdizimini takip eder. Yapılandırma dosyalarınızın doğru olduğundan emin olmak için GitLab, doğrulama için bir test aracı sunar. GitLab örneğinizin içinde, proje deponuzda, .gitlab-ci.yml dosyanızı doğrulamak için CI lint arayüzünü ziyaret edebilirsiniz. Sol navigasyon menüsündeki CI/CD seçeneğine tıklayın ve açılan sayfadaki CI lint butonuna tıklayın:

Yapılandırma dosyasındaki yönergeler aşağıda tartışılmaktadır.

• Temel Docker imajı

Yapılandırma dosyasındaki ilk satır, testleri çalıştırmak için kullanılması gereken bir Docker imajını bildirir. Bir Node.js uygulaması oluşturduğumuz için en son Node.js imajını kullanıyoruz:

• Aşamalar

Ardından, sürekli entegrasyon testlerimizin geçmesini istediğimiz farklı aşamaları tanımlıyoruz. Sadece iki aşamamız var:

Aşama adlarını tanımlarken, build veya test gibi adlar rastgele seçilir – istediğiniz herhangi bir adı seçebilirsiniz. Ancak, aşamaları düzgün bir şekilde sıralamalısınız çünkü bu, yürütme akışını belirler. Bizim durumumuzda, build aşamasındaki işler, test aşamasındaki işlerden önce yürütülür. GitLab runner, aynı aşamadaki işleri paralel olarak yürütecek ve bir sonraki aşamadaki işleri yürütmeye başlamadan önce tüm işlerin tamamlanmasını bekleyecektir.

• Önbellek

İş çalıştırmaları arasında daha sonra kullanılmak üzere önbelleğe alınacak veya kaydedilecek dosya ve dizinleri belirtmek için bir cache tanımı eklenmiştir:

Önbelleğe almayı tanımlamak, çalıştırmalar arasında değişmesi muhtemel olmayan kaynaklara dayanan işleri çalıştırmak için gereken süreyi en aza indirmeye yardımcı olur. Önbelleğe alınacak node_modules dizinini belirtiyoruz. Bu, npm aracının proje için bağımlılıkları yüklediği dizindir.

• İşler

Yapılandırmada iki işimiz var:

• install_dependencies

İşleri adlandırırken istediğiniz adı seçmekte özgürsünüz. Ancak, GitLab kullanıcı arayüzünde kullanıldıkları için açıklayıcı bir ad seçmeniz önerilir – bu, hata ayıklama sırasında yardımcı olabilir. Web'deki çoğu yapılandırmanın npm install test aşamasındaki komutlarla. Bu oldukça küçük bir proje olduğundan, işlerin nasıl etkileşime girdiğini göstermeye yardımcı olmak için bunları yalnızca ayırdık. stage yönergesi bu işi build olarak işaretler – build aşamasında çalıştırılır.

The script yönergesi, bu işin yürütülmesinde çalıştırılacak komutları belirtir. script bloğuna satırlar ekleyerek birden fazla komut belirtebilirsiniz. Tabii ki, girintileri düzgün ayarlamaya ve betiklerin hangi sırayla çalıştırılması gerektiğini akılda tutmaya dikkat etmeniz gerekir.

The artifacts yönergesi, aşamalar arasında kaydedilecek ve paylaşılacak dosyaları veya dizin yollarını belirtir. Aşamaları düzgün bir şekilde sıralamanın, diğer dosyaların çalışmak için ihtiyaç duydukları şeylere sahip olmasını sağlamak açısından çok önemli olduğunu tekrar hatırlatalım. npm install komutu, bağımlılıkları node_modules dizinine yükleyecektir. Bunu artifacts içinde bildirerek, sonraki aşamalarda yürütülen işlerin kullanımına sunmuş oluruz. İndirmek isterseniz dosyalar GitLab kullanıcı arayüzünde de sunulur.

• test_with_mocha

Bu iş test aşamasında çalıştırılır. Bu iş, build aşamasındaki iş çalıştıktan sonra çalıştığı için, build aşamasında bildirilen artifact'ler (uygulamamızın bağımlılıkları olan dosyalar) test aşamasında kullanılabilir olacaktır. Script bloğu, testlerimizi çalıştırmak için npm komutlarını belirtir. Önce uygulamamızı başlatırız ve ardından uygulamaya karşı testleri çalıştırırız. Bu komutların çalıştırılması, package.json script bloğu bölümünde belirtilen komutları tetikler:
Bununla birlikte, .gitlab-ci.yml dosyası hakkında temel bir anlayışa sahip olmalısınız. Temel diyoruz çünkü bu yalnızca statik bir hello world uygulamasıdır. Sırada, yeni bir CI çalışmasını nasıl tetikleyebileceğimizi görelim.

Adım 3: GitLab CI Çalışmasını Tetikleme

Deponuzda .gitlab-ci.yml dosyası yer aldığında, buraya göndereceğiniz her yeni commit'in yeni bir Sürekli Entegrasyon (CI) çalışmasını tetikleyeceğini bilmek sizi mutlu edecektir. Kendi kendine yönetilen (self-managed) GitLab örnekleri için, bir GitLab runner yapılandırmadıysanız, CI çalışması “pending” (beklemede) olarak ayarlanacaktır.

GitLab SaaS, kullanıcılara işlerini alıp otomatik olarak yürütebilecek bazı paylaşılan runner'lar (shared runners) sunar. Bu, yalnızca paylaşılan runner'lar boşta olduğunda ve kotanızı aşmadığınızda mümkündür. GitLab SaaS'ta, deponuzun shared runners kullanıp kullanmayacağını, projenizin Settings > CI / CD sayfasına giderek seçebilirsiniz (aşağıdaki ekran görüntüsünde gösterildiği gibi). Bu sayfada, bir sonraki adımda ayrıntılarına gireceğimiz GitLab runner kurulum talimatları hakkında da bilgi bulacaksınız:

Şimdi, bir CI çalışmasını tetiklemek için küçük bir değişiklik yapalım. Tekrar node_pipeline GitLab proje deponuza gidin:

Yukarıda vurgulanan README.md dosyasına tıklayarak görüntüleyin:

Dosyayı tarayıcıda düzenlemek üzere açmak için ‘Edit’ butonuna tıklayın ve biraz metin ekleyin:

Biraz metin ekledikten sonra aşağı kaydırın ve değişiklikleri kaydetmek için Commit changes butonuna tıklayın. Commit mesajını istediğiniz gibi değiştirebilirsiniz. Pipeline çalışırken GitLab kullanıcı arayüzünde bir başlık olarak görünecektir. Oldukça açıklayıcı olduğu için biz bunu Update README.md olarak bıraktık:

Değişiklikleri kaydettikten (commit) sonra ana proje sayfasına dönün. En son commit'in yanında küçük bir duraklatılmış simge olduğunu fark edeceksiniz. Farenizi simgenin üzerine getirirseniz şu şekilde görüntülenecektir: ‘Pipeline:pending’:

Bu, CI çalışmasının tetiklendiği anlamına gelir. Ancak testler henüz çalıştırılmamıştır. Soldaki navigasyon menüsünde CI/CD, seçeneğine tıklayın, ardından Pipelines. seçeneğini belirleyin. Bu, pipeline hakkında daha fazla ayrıntı gösteren bir sayfa açacaktır. CI'ın beklemede (pending) olduğunu ve takılı (stuck) olarak işaretlendiğini görebilirsiniz:

Çalışma hakkında daha fazla ayrıntı almak için pending durumuna tıklayın. Çalışmanın farklı aşamalarını ve her bir aşamaya bağlı bağımsız işleri gösteren aşağıdaki görünümü göreceksiniz:

Gecikmelere neyin sebep olduğu gibi daha ince ayrıntılarını görmek için tek tek işlere de tıklayabilirsiniz. Başarısız çalıştırmalar durumunda, işin başarısız olmasına neyin sebep olduğunu burada göreceksiniz:

Mesaj, bu işi yürütebilecek herhangi bir aktif runner yapılandırmadığınız için işin takıldığını gösterir. Bunu bir sonraki adımda yapacağız. Bir runner'ı kullanılabilir hale getirdiğinizde, iş otomatik olarak yürütülmeye başlayacaktır. Bir iş yürütüldüğünde, çıktıyı bu arayüzde ve iş çalışırken oluşturulan diğer indirilebilir çıktıları (artifacts) göreceksiniz.

Adım 4: GitLab CI Runner Servisinin Kurulması

Şimdi bu kılavuzun Önkoşullar bölümünde belirttiğimiz ikinci sunucudan yararlanma zamanı. Bu sunucuya bir GitLab runner servisi kurup yapılandıracağız. Servisi, GitLab'daki farklı projeler için birden fazla runner örneği çalıştıracak şekilde dağıtabilirsiniz.

Runner'ı, kendi yönettiğiniz GitLab örneğinizi barındıran aynı sunucuya dağıtma seçeneğiniz vardır. Ancak, bir örneğin kaynaklarla sınırlı kalmamasını sağlamak için ayrı bir CI runner örneği kurmak daha tercih edilebilirdir. Hangi yapılandırmayı seçerseniz seçin, Docker kurulu olmalıdır test ortamlarını izole etmek için.

GitLab CI runner'ı kurma süreci, kendi kendine yönetilen GitLab'ı kurma süreciyle karşılaştırılabilir. Resmi GitLab deposunu apt kaynaklarına eklemek için aşağıdaki komutu kullanarak bir betik indirmekle başlıyoruz:

İstendiğinde root şifrenizi girin. Ardından, en son GitLab CI runner'ı yüklemek için komutu çalıştırabilirsiniz:

Yukarıdaki komut, projeleriniz tarafından kullanılmaya hazır bir runner servisi kurar ve kaydeder.

Adım 5: Kayıt Belirteçlerini Alma ve GitLab Runner'ı Bağlama

Bir GitLab CI runner'ını işleri kabul etmeye başlayacak şekilde ayarlamak için bir GitLab runner belirtecine ihtiyacınız vardır. Bu, runner'ın GitLab sunucu örneğinizle kimlik doğrulaması yapması için gereklidir. Runner'ı nasıl kullanmak istediğinize bağlı olarak iki tür belirteç vardır: projeye özel ve paylaşılan runner.

Projeye özel runner'lar runner için benzersiz gereksinimleriniz varsa geçerlidir. Örneğin, gitlab-ci.yml dosyanızda benzersiz belirteçlere sahip dağıtım tanımlarınız varsa, dağıtım ortamında doğru şekilde kimlik doğrulaması yapmak için özel bir runner önerilebilir. Diğer bir husus ise, sürekli entegrasyon aşamalarınızın yoğun kaynak tüketen süreçlere sahip olup olmadığıdır. Bu durumda, projeye özel bir runner ile devam etmek ideal olacaktır. Projeye özel bir runner'ın diğer projelerden gelen işleri kabul etmediğini unutmayın.

Paylaşılan runner'lar genel amaçlıdır ve birden fazla proje tarafından kullanılabilir. GitLab Inc üzerinde barındırılan GitLab SaaS örneği, Üçüncü Adım bölümünde açıklandığı gibi işlem hatlarınızı otomatik olarak alacak bazı paylaşılan runner'lara sahiptir. Runner'lar, her proje için o anda yürütülmekte olan iş sayısını hesaba katan bir algoritmaya dayalı olarak yapılandırmalarınızdan işleri alır. Paylaşılan bir runner, özel bir runner'dan daha esnektir. GitLab örneğinin yönetici hesabından yapılandırılabilir. Her iki runner için de belirteçleri nasıl alabileceğimize bakalım.

• Projeye Özel Runner Kaydetme

Projeye özel bir runner kaydetmek için projenizi GitLab örneğinizde veya GitLab SaaS hesabınızda açın. Soldaki navigasyon menüsünden Settings öğesine tıklayın ve CI/CD seçeneğini seçin:

Bundan sonra, aşağı kaydırarak Runners bölümüne gelin ve bölümü genişletmek için düğmeye tıklayın:

Sol taraf, projeye özel bir runner'ın nasıl kaydedileceğini açıklar. Bu, GitLab SaaS örneğinin bir görünümüdür. Kubernetes ile otomatik runner'lar da yapılandırabilirsiniz, ancak bu kılavuz için manuel runner kurulumu yapıyoruz:

Ardından, bu proje için size token verilen bölüme odaklanmanız gerekir. Kendi kendine yönetilen bir GitLab örneği için URL, GitLab örneğinizin üzerinde çalıştığı sunucunun alan adını gösterecektir:

Sağ taraftaki bölümün altında bulunan anahtarı kapatarak bu proje için paylaşılan çalıştırıcıları devre dışı bırakmayı seçebilirsiniz: Shared Runners. Ardından, daha sonra kullanacağımız için görüntülenen kayıt token'ını not defterinize kopyalayın.

• Paylaşılan Çalıştırıcı Kaydetme

Paylaşılan bir çalıştırıcı kaydetmek için, kendi kendine yönetilen GitLab örneğinize yönetici olarak giriş yapmanız gerekir. Yönetici paneline erişmek için üst gezinti menüsündeki ingiliz anahtarı simgesine tıklayın:

Şu panelde: Yönetici Paneli, sol menünün Runners bölümündeki Genel Bakış kısmına tıklayın. Bu, şu yapılandırma talimatlarını içeren bir sayfa açacaktır: Shared Runners yapılandırma talimatları:

Sağ tarafta şu başlık altında görüntülenen kayıt token'ını kopyalayın: Set up a shared Runner manually. Bir sonraki adımda çalıştırıcıyı kaydetmek için bu token'ı kullanacaksınız.

• Bir GitLab CI Çalıştırıcısını bir GitLab Örneği ile Bağlama

Bu adımda, GitLab örneğinizi CI çalıştırıcısı ile bağlayacaksınız. GitLab çalıştırıcı hizmetini kurduğunuz sunucuya tekrar giriş yapın: Dördüncü Adım. Çalıştırıcı kayıt işlemini başlatmak için terminalinizde aşağıdaki komutu girin:

Komut size bir dizi soru soracaktır:

• GitLab örneği URL'sini girin (örneğin, https://gitlab.com/):

SSL belirtmek için https:// kullanarak GitLab örneğinizin alan adını sağlayın.

• Kayıt token'ını girin:

Kayıt token'ınızı sağlayın. Burası, bu çalıştırıcının projeye özel mi yoksa paylaşılan mı olmasını istediğinizi seçeceğiniz yerdir. İki seçenekten biri için yalnızca daha önce kopyaladığınız token'lardan birini sağlayabilirsiniz.

• Çalıştırıcı için bir açıklama girin:

GitLab örneği arayüzünde görüneceği için CI çalıştırıcınız için açıklayıcı bir ad seçin.

• Bir yürütücü (executor) girin: custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes:

Burada, işleri çalıştırmak için bir yürütücü seçmeniz için seçenekler sunulur. Şunu girin: Docker.

• Çalıştırıcı için etiketler girin (virgülle ayrılmış):

Bu isteğe bağlıdır. Bu çalıştırıcının içerdiği bağımlılıklar gibi herhangi bir etiket adı girebilirsiniz. Şimdilik boş bırakabilirsiniz.

• Varsayılan Docker imajını girin (örneğin, ruby:2.6):

Burada, gitlab-ci.yml dosyasının bir imaj belirtmemesi durumunda işleri çalıştırmak için kullanılacak varsayılan genel amaçlı bir imaj belirtmeniz beklenir. Şunu girin: alpine:latest çünkü bu küçük, genel amaçlı ve güvenli bir imajdır. Enter tuşuna bastığınızda çalıştırıcı kaydedilecek ve otomatik olarak başlatılacaktır:

Şu anda mevcut olan çalıştırıcıların listesini görüntülemek için aşağıdaki komutu girin:

Adım 6: CI Çalıştırıcısının GitLab'da Başarıyla Bağlandığını Doğrulama

Ardından, tarayıcınıza dönün ve GitLab örneğindeki proje sayfanızı ziyaret edin. Çalıştırıcıyı kaydetmenizin üzerinden kaç dakika geçtiğine bağlı olarak, işin şu anda çalışmakta olduğunu görebilirsiniz:

Veya tamamlanmış olabilir:

Bundan sonra, sol menüdeki Pipelines sayfasına gidin; bunu ya sol menüdeki CI/CD > Pipelines seçeneği üzerinden ya da running, passed, veya failed simgesine tıklayarak (ardışık düzen hatalarla karşılaştıysa) CI çalışmasının durumunu görüntüleyebilirsiniz. Burada aşamalardan birinin (build stage) geçtiğini, diğerinin ise hala çalışmakta olduğunu görebiliriz:

Tabloda, Stages başlığı altında, ilişkili işleri görüntülemek için aşama simgelerinden birine tıklayın:

Ardından, ayrıntıları görüntülemek için açılır penceredeki bir işe tıklayın:

İş çalıştı ve npm komutu bağımlılıkları yüklerken ilerlemeyi görebilirsiniz. Sağ tarafta, diğer ilgili bilgileri görüntüleyebilirsiniz. İşten elde edilen çıktıları (artifacts) indirme seçeneğiniz vardır. Ayrıca açılır menüden diğer işleri görüntülemek için aşamalar arasında geçiş yapabilirsiniz.

Burada, test aşamasındaki işi seçtiğinizde gösterilen test senaryolarımızı görüntüleyebilirsiniz:

Mevcut Çalıştırıcılar

Sol menüde, Settings > CI/CD seçeneğine tıklar ve Runners bölümünde, az önce kaydettiğiniz runner'ı görmelisiniz. Projeye özel bir token mı yoksa paylaşılan bir token mı belirttiğinize bağlı olarak, runner sırasıyla ilgili bölümde görünecektir.

Burada projeye özel bir token kaydettiğimizi görebilirsiniz. Runner şu başlık altında görünür: Specific Runners:

Sonuç

Bu eğitimde, testlerinizi GitLab CI ile nasıl otomatikleştirebileceğinizi öğrendiniz. GitLab üzerinde bir Node.js uygulama projesi kurarak başladık. Proje bazı test senaryoları ve bir gitlab-ci.yml dosyası içeriyordu. GitLab'in tetiklendiğinde ne yapacağını belirlemek için gitlab-ci.yml dosyasını kullandığını öğrendik. Bir gitlab-ci.yml dosyası, sadece uygulamaları derleme ve test etme talimatlarını içeren, bir GitLab CI runner'ının anlayabileceği YAML formatında yazılmış bir yapılandırma dosyasıdır.

Ayrıca ayrı bir sunucuda bir GitLab CI runner kurmayı da başardık. Bir tetikleme olduğunda GitLab örneklerimizden işleri alması için onu kaydettik. Bu basit bir proje olsa da, karmaşık projeler için işlem hatları (pipelines) kurmak üzere bu bilgilerden yararlanabilirsiniz. GitLab'e bir proje ekleme ve bir GitLab CI runner bağlama adımları aynı kalır. Değişen şeyler ise gitlab-ci.yml dosyasındaki talimatlar ve aşamalardır.

Keyifli Çalışmalar!