GitHub Actions Nedir? CI/CD Nedir?
Herkese merhaba, hadi biraz GitHub Actions’dan bahsedelim.
Öncelikle CI/CD (continuous integration, continuous delivery) süreçlerinin ne olduğunu bilmekte fayda var. CI, sürekli entegrasyon demektir. Sürekli entegrasyonun ana hedefi, kod üzerinde yapılan her değişiklikten sonra yazılan kodun derlenebilmesi ve test edilebilmesi diyebiliriz. Böylelikle bu süreçte bir hata alınırsa kodun merge olmayacağını biliriz. CD ise, CI sürecinin devamı niteliğinde olup ilgili ortamlara otomatik olarak yayımlanma işlemidir.
Artık yazılım dünyasında CI/CD süreçleri olmadan yazılım geliştirmek eskide kaldı diyebiliriz. CI/CD için popüler tool’lara Jenkins, CircleCI, TeamCity, GitLab vb. örnek olarak verilebilir. Biz de, ileride çok popüler olacağına hiç kuşkumuzun olmadığı GitHub Actions’ı anlatmak ve nasıl kullanıldığından bahsetmek istiyoruz.
Kısaca GitHub Actions için, GitHub üzerinde bulunan, yazılım geliştirme süreçlerinin otomatize edilebilmesini sağlayan bir özellik diyebiliriz. Birden çok aksiyon türü ile GitHub Actions’ı tetiklemek mümkün. (X repository’sine bir commit yapıldığında, Y branch’ine pull request yapıldığında vb.) GitHub Actions dolayısıyla kodun build, test veya deploy edilmesini sağlayan CI/CD akışlarını direkt GitHub aracılığıyla ilgili repository üzerinde tutabildiğimiz ve buradan çalıştırabildiğimiz bir yapıdır.
Akla gelebilecek sorulardan biri de GitHub Actions’ın ücretli olup olmadığı olabilir. GitHub Actions, public GitHub repository’lerinde ücretsiz; private repository’lerde ise ücretli ve bu tutar CI/CD sürecinin çalışma süresi başına ücretlendiriliyor. Resimden de anlaşılacağı üzere 2000 dakikaya kadar ücretsizken (Free) aşılan her dakika başına ilgili makinenin dakika ücreti ile çarpılarak bir hesaplama yapılır. Ancak self-hosted’ın ücretsiz olduğunu belirtmekte fayda var.
Biz bu makalede, klasik bir Asp.NET Web projesinin GitHub Actions ile CI/CD süreçlerinin nasıl yönetileceğinden bahsetmeye çalışacağız.
Workflow Oluşturma
Bir workflow, repository’e eklediğiniz otomatik bir prosedürdür. Workflow’lar, bir veya daha fazla işten oluşur ve bir olay ile tetiklenebilir. Workflow, GitHub’da bir projeyi test etmek, yayımlamak veya dağıtmak için kullanılabilir.
GitHub’da herhangi bir repository’mizi görüntülediğimizde Actions sekmesi ile karşılaşırız. Actions sekmesini açtığınızda karşınıza eğer varsa workflow’larınız çıkar yoksa da new workflow butonu ile yeni bir workflow oluşturabiliriz.
Tabii ki her projenin CI/CD süreçleri aynı olmayabiliyor lakin bir çok aşama ortak olduğundan, workflow template’lerinin kullanımının faydalı olacağını düşünüyoruz.
Workflow, CI/CD süreçleri için yapılacak her türlü job’ların (X projesinin build edilmesi, Y dizinindeki dosyaların Z dizinine aktarılması vb.) tanımlandığı, sıralandığı ve bu sürecin hangi olaylarda tetikleneceği gibi bilgilerin tutulmasını sağlayan sistemdir.
Workflow’daki action’lar YAML dosya formatında yazılırlar.
New workflow aşamasında GitHub bizlere hazır workflow template’leri sunar. (Örnek: .NET, .NET Desktop)
Ya da kendi workflow’umuzu sıfırdan kendimiz de hazırlayabiliriz.
Biz örnek workflow’umuzu kendimiz yapacağız. Set up a workflow yourself’e tıklayarak devam ediyoruz. Actions bizden .yml uzantılı bir dosya oluşturmamızı istiyor. Dosya varsayılan olarak repository’de .github/workflows/example.yml yolunda oluşuyor.
Bu .yml dosyası bizim workflow’umuz oluyor. Burada adım adım build ve deploy ile ilgili step’lerimizi ekliyor olacağız.
YAML Dosyası Step’lerinin Açıklanması
on: On keyword’ü, aksiyonun hangi durumlarda tetikleneceği bilgisini belirten başlangıç adımı diyebiliriz.
main branch’ine yapılan her commit’te ve pull request’te job’ların tetiklenmesini istersek:
jobs: Workflow’da alınacak tüm aksiyonların yani job’ların tanımlandığı kısımdır. Jobs’dan sonra yazdığımız ilk parametre job’ın GitHub Actions tarafındaki ismidir — bizim case’imizde bu parametre build. Daha detaylı anlatmak için önce birkaç örnek üzerinden gitmekte fayda var.
runs-on: İşin hangi platformda çalışacağını belirttiğimiz kısımdır. (windows-latest, macos-latest, ubuntu-latest)
steps: Job’ın istenilen aksiyonu yerine getirmesi için yapılacak tüm action’ların adım adım belirtildiği kısımdır. Örneğin; ilgili branch’te checkout yapmak, dosyaları publish etmek, Docker container çalıştırmak gibi…
Step’leri name etiketi (-name) ile isimlendirebiliyoruz. Uses etiketi (-uses) ile de GitHub’ta tanımlı standart aksiyonların da bulunduğu aksiyonları kullanabiliyoruz. (Checkout işlemi, publish işlemi vb.)
Runner Nedir? Nasıl Oluşturulur?
Runner, GitHub Actions üzerindeki workflow’u çalıştıran GitHub ile sunucu arasındaki bağlantıyı sağlayan uygulamadır. İşletim sistemi farketmeksizin çalıştırılabilir. GitHub bize iki şekilde runner kullanma imkanı sunmuştur:
1) GitHub-Hosted Runner (Virtual Environment)
GitHub’ın bize sunduğu workflow’ları çalıştırmak için içinde hazır bir şekilde runner yüklenmiş sanal makineler mevcuttur. Bu makinelerdeki araçların ve runner’ların güncellemeleri ve bakımları GitHub tarafından yapılır. Bu sanal makinelerin özellikleri aşağıdaki gibidir:
Herhangi bir sanal makinedeki runner’ı kullanmak için etiketler mevcuttur. GitHub sanal makinelerinde bulunan runner’ların işletim sistemi ve etiketleri aşağıdaki gibidir:
Bu etiketleri yukarıda bahsetmiş olduğumuz workflow dosyalarında kullanabilirsiniz. Kullanım senaryolarını aşağıda anlatacağımız adımlarda ayrıntılı bir şekilde görebilirsiniz. 😊
“Peki bu runner’ları kendimiz oluşturamaz mıyız? Kendi bilgisayarımızda ya da kendi sunucumuzda çalıştıramaz mıyız?” dediğinizi duyar gibiyiz. İşte burada GitHub’ın bize sunduğu ikinci runner kullanım şeklinden bahsedelim:
2) Self-Hosted Runner
GitHub, üç çeşit runner oluşturmanızı sağlayabilme imkanı verir:
- Repository-level runners: Tek bir repository için kullanılabilir.
- Organization-level runners: Bir organizasyonda bulunan tüm repository’ler için kullanılabilir.
- Enterprise-level runners: Bir kurum içinde bulunan tüm organizasyonlar için kullanılabilir.
Runner uygulamaları açık kaynak kodludur. Runner havuzuna katkıda bulunabilir ve sorunları dosyalayabilirsiniz. Yeni bir sürüm yayımlandığında, runner uygulaması, runner’a bir iş atandığında veya runner’a herhangi bir iş atanmamışsa yayımlandıktan sonraki bir hafta içinde otomatik olarak kendini günceller. Oluşturduğunuz runner GitHub Actions’a 30 günden fazla bir süredir bağlanmadıysa, GitHub’dan otomatik olarak kaldırılır.
Kullanım limitleri aşağıdaki gibidir:
- Workflow çalışma saati — Bir workflow en fazla 72 saat çalışabilir.
- Job queue time — Job’lar queue’da en fazla 24 saat durabilir.
- API requests — 1 saat içinde 1000 API call yapılabilir.
- Job matrix — Bir workflow’da 256 job çalışabilir.
Runner oluşturulabilen işletim sistemleri:
Self-Hosted Runner Oluşturma
1) Repository’nizin settings bölümüne gidilir.
2) Actions tab’ına tıklanır.
3) Actions tab’ı içerisindeki self-hosted runners bölümünde bulunan Add Runner butonuna basılır.
4) Runner’ın kurulacağı işletim sistemi seçilir.
5) İlgili komutlar runner’ın kurulacağı makinedeki command window’da çalıştırılır.
Not: Invoke-WebRequest komutu Windows işletim sistemine kurulurken çalışmaz ise komutta bulunan linki kullanarak zip dosyasını indirdikten ve çıkardıktan sonra komut satırında çıkardığınız dosyaya giderek configure içindeki komutları çalıştırabilirsiniz. Artık runner’ınız o dosyanın altında olacaktır.
6) Actions tab’ı altında, oluşturulan runner’ı, oluştururken verdiğiniz isim ve etiketlerle görebilirsiniz.
Oluşturulan runner’ı aynı zamanda makinenizdeki services’ların altından açıp kapatabilirsiniz.
Marketplace
Actions sekmesine girip new workflow dedikten sonra sağ tarafta bulunan marketplace bölümünden gerekli action’ları arayarak bulabilirsiniz. Buradaki GitHub Actions tarafından hazırlanan actions’lar hariç diğer third party actions’lar sadece Linux ve Docker üzerinde çalışmaktadır.
Örnek Bir Workflow Oluşturma
Şimdi de örnek projemiz olan GitHub’da yayımladığımız, aşağıda linki bulunan proje için workflow oluşturalım. Bu workflow’un çalışma adımlarını projenin Actions bölümünde monitor edebilirsiniz.
https://github.com/mertakk/DotNetGithubActionsExample
YAML Dosyamızın Tercümesi
- Biz workflow’umuzun adını DotNetGithubActionsExample CI şeklinde tanımladık.
- Workflow’umuzun main branch’ine yapılan her commit ve pull request’te tetiklenmesi için gerekli ayarları yaptık. (on)
- Tek job’ımız olan build job’ının hangi runner (makine) üzerinde çalışacağını, biz kendi oluşturduğumuz runner ile bu işlemi gerçekleştireceğimiz için, self-hosted etiketi ile tanımladık. Ancak burada GitHub’ın hazırlamış olduğu sanal makinelerde bulunan runner’larla da çalışmak için windows-latest gibi etiketleri de kullanabiliriz. (runs-on)
Ve artık job’ımızın çalışacağı adımları step’lerde teker teker tanımladık. Bunlardan kısaca bahsedelim:
- Projenin main branch’ine checkout yapılır. Bunun için GitHub’ın hazırlamış olduğu şu action’ı kullandık: actions/checkout@v2
- Build yapacağımız tool’u seçtik: microsoft/setup-msbuild@v1
- NuGet paketlerini restore edecek tool’u seçtik: NuGet/setup-nuget@v1.0.5
- Projemizin NuGet paketlerini restore ettik. nuget restore…
- Projemizi _build klasörüne build ettik. msbuild … /p:outdir=”c:\_build\\”
- PowerShell komutlarıyla _build klasöründe oluşan dosyalarımızı _deploy klasörüne aktardık. Not: run komutundan sonra konulan | işaretinden sonra Shell komutları yazabiliriz ya da Shell dosyası çalıştırabiliriz.
- Oluşan _deploy klasörümüzü Actions’ın altında bulunan ilgili çalışan Job’ın içine created-artifact ismiyle upload ve download yaptık. Bu dosyayı backup olarak düşünebiliriz.
Job çalışırken ya da tamamlandıktan sonra action’ların durumları aşağıdaki ekrandan kontrol edilebilir.
Farklı Kullanım Örnekleri
Bir Vue projesinin GitHub Actions ile GitHub Pages’a deploy işlemini aşağıda görebilirsiniz:
Bir .NET Core projesinin GitHub Actions ile build ve deploy işlemlerini aşağıda görebilirsiniz:
Umarım faydalı ve anlaşılır bir yazı olmuştur.
Makaleyi yazarken katkı veren değerli mesai arkadaşlarım Fatih ÜNLÜ ve Enes BABAOĞLU’ya teşekkür ederim.
Başka yazılarda görüşmek üzere…
