Github Actions vs Jenkins | Hangisini seçmeliyiz?
Son yıllarda DevOps, yazılım yaşam döngüsünün önemli bir parçası haline gelmiş durumda. Bu durum, önde gelen birçok DevOps aracının ve uygulamaların büyümesine yol açtı. CI/CD süreçlerini geliştirmek isteyenler için bir sürü tool bulmak daha da kolaylaştı. Jenkins ve Github Actions, DevOps’lar arasında gerçekten iddaalı ve sektörde çok kullanılıyor. Bizde bu yazıda Github Actions’ın Jenkins ile ne farkları var bunlardan bahsetmeye çalışacağız.
Başlamadan …
Eğer GitHub Actions’a yeni başlıyor , “Runner nedir?”, “Workflow nasıl oluşturulur?” gibi sorulara cevap arıyorsanız veya daha temel bilgileri edinmek istiyorsanız, aşağıda linki bulunan bir önceki makalemizi incelemenizi tavsiye ederiz.
Farklar nelerdir ?
Jenkins ve GitHub Actions, CI/CD süreçlerini yöneten, test eden, yayınlayan ve dağıtan iş akışları oluşturmanıza olanak tanır.
Jenkins deploymentları genellikle self-hosted olur ve kullanıcılar sunucularını kendi veri merkezlerinde tutar. GitHub Actions ise jobları çalıştırmak için kullanabileceğiniz runner’larını barındırır ve bu runnerlar hem kullanıcıların veri merkezlerinde olabilir hem de github’ın bulut sunucularında bulunabilir.
GitHub Actions github tarafından tam olarak yönetildiği için arka planda neler olduğunu bilmeniz gerekmiyor. Ancak jenkinste yapılan işlerin tüm yönetimi sizin tarafınızda olmak zorundadır.
Kısaca farklılıkları bir tablo ile göstermek gerekirse :
— Yazımızın devamında Jenkins te hazırlanan bir pipeline ı nasıl github actions a çevirebiliriz bundan bahsederek seçiminizi kolaylaştırmak isteriz.
Jenkins’teki Deployment Akışını GitHub Actions ile Sağlama
- Jenkins te plugin ve powershell komutlarıyla yapılan akış adımları GitHub Actions’ta action’lar aracılığıyla yapılır. Bu action’lar GitHub’ın kendi action’ları olabilir. Gerekli olan dosyaları adımları ve komutları bu actionları kullanarak çalıştırabilir ve kullanabilirsiniz.GitHub actionları her makinede çalışır.
— Third party actionlar da olabilir. Ve bu third party actionlar geliştiriciler tarafından ihtiyaca göre yazılır. Third party actionlar sadece Linux sunucularındaki runner’larda çalışır.Aşağıdaki Code Coverage summary Report bu actionlardan biridir.
— Yukarıdaki Actionla birlikte her pull request oluşturulduğunda job tetiklenir ve yazılan unit testlerin sonucunda çıkan coverage raporu pull requeste yorum olarak gönderilir. Örnek çıktı :
2. Jenkins’de ki plugin manager olduğu gibi bütün actionları GitHub’ın marketplace’inde bulabilirsiniz. Buradan örnekleri alarak kendi akışınıza dahil edebilirsiniz.
3. Bu akışlarda actionlar ile build-deploy yapılabilir, Shell komutları çalıştırılabilir; test kontrolü yapılabilir, code coverage raporu çıkarılabilir.
— Yukarıdaki build ve publish actionlarında olduğu gibi projenizi build ve publish işleminizi gerçekleştirebilirsiniz. Publish yaparken web.config transform yapmak isterseniz -c (configuration) komutundan sonra Release yerine istediğiniz web.config değişimini sağlayabilirsiniz.Ancak bu değişimi yaparken projenizin derleme veya yapılandırma ayarlarını değiştirebilirsiniz.
— Yukarıda ki deploy örneğinde görüldüğü üzere run komutu ile shell scripti çalıştırdık. Çünkü bu proje için çalışan self-hosted runner linux sunucusunda çalışmaktadır. Bu nedenle powershell değilde shell scripti kullanarak windows sunucusuna deploy yapılmıştır. Shell komutunun içinde github secretlar kullanılmıştır. Deploy işlemi yapılırken sunucular aynı ağa bağlıdır.
4. Bu akışlarda otomatik olarak commit atıldığında ya da Pull Request oluşturulduğunda job’ı tetikleyebilir veya manual olarak inputslar aracılığıyla branch, ortam seçilebilir veya herhangi bir parametre job’ın içine gönderilerek job tetiklenebilir.
— Otomatik olarak jobları yukarıda yazıldığı şekilde tetikleyebilirsiniz.
— Manual olarak tetiklemek için yaml dosyanızın on kısmına yukarıda gösterildiği şekilde workflow_dispatch altına inputslar tanımlayarak jobınızın çalışmanızı sağlayabilirsiniz. Örneğin yukarıdaki inputs un amacı job ı environmentlara göre tetiklemek için kullanılmıştır. Verilen environment a ve seçilen branche göre sunucu değişimi yapılır. Required flagi ile bu inputu zorunlu kılabilirsiniz. Bu eklemeden sonra Workflow bu şekilde görüntülenecektir:
— Yukarıda jobı manual olarak tetiklerken yazdığımız inputu yaml dosyası içinde aşağıdaki gibi kullanabilir workflow akışını değiştirebilirisiniz.
— Detaylı yaml dosyasının bir örneğini başta bahsetmiş olduğumuz yazımızda görebilirisiniz.
SONUÇ
Kurmuş olduğunuz sistemde jenkins ile devops süreçleri yolunda gidiyor, hazırladığınız joblarınız düzgün çalışıyor ve maliyeti de sizin için sorun değilse Jenkins’de kalmanızı tavsiye ederiz.
Daha iyi alternatifler arıyorsanız, zaten GitHub’ı source control platformu olarak da kullanıyorsanız GitHub Actions düşünmeniz gereken ilk DevOps toollarından biridir.
Umarım faydalı ve anlaşılır bir yazı olmuştur.
Makaleyi yazarken katkı veren değerli mesai arkadaşlarım Fatih Ünlü ve Mert AKKAYA’ya teşekkür ederim.
Başka yazılarda görüşmek üzere…
