GitHub Actions ile Otomasyon: Workflow Yazma Rehberi

GitHub Actions nedir, neyi otomatikleştirir?

GitHub Actions, kod deposunun içinde tanımlanan ve depoda gerçekleşen olaylara tepki veren bir otomasyon sistemidir. Bir değişiklik gönderildiğinde testleri koşturabilir, birleştirme isteği açıldığında kod denetimi yapabilir, etiket oluşturulduğunda paket yayınlayabilir ya da belirli saatlerde zamanlanmış bir bakım işi çalıştırabilir.

Akışlar kodla birlikte sürüm kontrolünde durur. Yani otomasyonun kendisi de gözden geçirilebilir, geri alınabilir ve dallara göre farklılaşabilir. Bu, ayrı bir sunucuda elle bakılan bir derleme sisteminden temel farkıdır.

Sistemin kapsamı yalnız yazılım derlemesiyle sınırlı değildir. Sorun kayıtlarına otomatik etiket atamak, bağımlılık güncellemelerini denetlemek, dokümantasyonu yayınlamak ve düzenli raporlar üretmek de aynı mekanizmayla yapılır.

Bir workflow'un yapısı

Workflow, deponun içinde .github/workflows klasöründe duran bir YAML dosyasıdır. Her dosya bir otomasyon akışını tanımlar ve şu kavramlardan oluşur:

• Olay (on): Akışı neyin başlatacağı. Dala gönderim, birleştirme isteği, zamanlayıcı ya da elle tetikleme olabilir.
• İş (job): Birbirinden bağımsız çalışan, kendi ortamı olan bir görev bloğu. İşler varsayılan olarak paralel koşar; sıraya sokmak için bir işin diğerine bağlı olduğunu belirtirsiniz.
• Çalıştırıcı (runner): İşin koştuğu makine. GitHub'ın sunduğu hazır makineler ya da kendi sunucularınızdaki çalıştırıcılar kullanılabilir.
• Adım (step): Bir işin içindeki sıralı komutlar. Bir adım ya doğrudan kabuk komutu çalıştırır ya da hazır bir eylem (action) kullanır.
• Eylem (action): Tekrar kullanılabilir iş parçası. Depoyu makineye indirmek, bir dil ortamını kurmak ya da önbellek yönetmek için topluluğun ve GitHub'ın hazır eylemleri vardır.

Bu kavramlar oturduğunda herhangi bir örnek dosyayı okuyup ne yaptığını çözebilirsiniz. Dosyadaki girinti YAML'de anlam taşır; yanlış boşluk en sık karşılaşılan söz dizimi hatasıdır.

İlk workflow'u adım adım yazmak

Örneğin bir uygulamanın her birleştirme isteğinde testlerinin koşmasını istediğinizi düşünelim. Akış şu mantıkla kurulur.

• Önce olayı seçin: birleştirme isteği açıldığında ve ana dala gönderim yapıldığında çalışsın.
• Bir iş tanımlayın ve çalıştırıcı olarak GitHub'ın hazır Linux makinesini seçin.
• İlk adımda depo kodunu makineye indiren hazır eylemi çağırın. Bu adım olmadan makinede kodunuz bulunmaz; yeni başlayanların sık unuttuğu kısım budur.
• Sonra dil ortamını kuran eylemi ekleyin ve kullandığınız sürümü açıkça yazın.
• Bağımlılıkları kuran ve testleri çalıştıran komutları ayrı adımlara bölün. Ayrı adımlar, hata olduğunda günlükte nerede kırıldığını net gösterir.
• Dosyayı depoya gönderin ve deponun Actions sekmesinden koşuyu izleyin. İlk deneme çoğu zaman bir söz dizimi ya da yol hatasıyla kırılır; günlük satırı sorunu gösterir.

Çalışan sade bir akışla başlayın, sonra genişletin. Baştan karmaşık bir dosya yazmak, hatanın nereden geldiğini bulmayı zorlaştırır.

Matris, önbellek ve yeniden kullanım

Aynı testi farklı ortamlarda çalıştırmanız gerekiyorsa matris (matrix) stratejisi kullanılır. Birden çok dil sürümünü ya da işletim sistemini aynı tanımla dener; her kombinasyon ayrı iş olarak paralel koşar. Hangi kombinasyonların gerçekten gerekli olduğunu seçin, çünkü her biri çalışma süresi ve kaynak tüketir.

Bağımlılıkların her koşuda baştan indirilmesi akışı yavaşlatır. Önbellek eylemi, değişmeyen bağımlılıkları koşular arasında saklayarak süreyi kısaltır. Önbellek anahtarını bağımlılık dosyasının içeriğine bağlarsanız, dosya değiştiğinde önbellek kendiliğinden yenilenir.

Aynı adımları birçok depoda tekrar ediyorsanız yeniden kullanılabilir workflow ve kendi bileşik eylemlerinizi yazın. Bir değişikliği merkezi bir yerde yapıp tüm depolara yaymak, kopyala yapıştır akışların dağılmasını önler.

Gizli değişkenler, ortamlar ve izinler

Parola, erişim anahtarı ve belirteçleri workflow dosyasına yazmayın. Depo ya da kurum ayarlarında tanımlanan gizli değişkenler (secrets) akışa çalışma anında verilir ve günlüklerde maskelenir.

Canlıya dağıtım yapan işleri ortam (environment) kavramına bağlamak iyi bir alışkanlıktır. Ortam, hangi gizli değişkenlerin hangi işe açılacağını ayırır ve canlı ortam için onaylayıcı gerektirebilir. Böylece bir hata ya da kötü niyetli değişiklik canlı anahtarlara kolayca ulaşamaz.

Akışın kullandığı belirtecin yetkisini de kısıtlayın. Akışın yalnız okuması gereken bir işte yazma yetkisi vermek gereksiz risktir. Harici eylemleri kullanırken de bir sürüm etiketine ya da sabit bir kaydın özetine bağlanmak, eylemin sonradan değiştirilip akışınıza zarar vermesi ihtimalini azaltır. Hangi eylemlere güvendiğinizi bilinçli seçin.

Sık yapılan hatalar

• Depo kodunu indirme adımını atlamak ve dosyaları bulamamak.
• YAML girintisini bozmak. Düzenleyicide söz dizimi denetimi açmak bu hataların çoğunu yayından önce yakalar.
• Her değişiklikte tüm testleri ve tüm matris kombinasyonlarını koşturmak. Süre uzar, ekip bekler, akış sevilmez olur.
• Gizli değişkenleri komut çıktısına basmak. Maskeleme bir güvenlik ağıdır, değerleri bilinçli olarak yazdırmayın.
• Başarısız akışı görmezden gelmek. Kırmızı koşunun kimin sorumluluğunda olduğu belli olmalıdır.
• Harici eylemleri incelemeden eklemek. Kaynağını ve bakımını değerlendirin.
• Hata ayıklamayı yalnız dosyayı sürekli değiştirerek yapmak. Günlükleri okumak ve adımları küçük tutmak daha hızlı yol gösterir.

Alışkanlık olarak, her yeni workflow'u küçük bir dalda deneyin ve birleştirme isteğinde ekip arkadaşınıza okutun. Otomasyon dosyası da diğer kod gibi gözden geçirmeyi hak eder.

Öğrenme yolu: temelden ileriye

Başlangıç aşamasında olay, iş, adım ve eylem kavramlarını yerleştirin ve test koşturan bir akış yazın. Sonraki aşamada önbellek, matris ve gizli değişkenlerle akışı gerçek bir projeye uyarlayın. Ardından konteyner imajı üretip bir ortama dağıtan akışlar kurun, ortam onaylarını ekleyin.

İleri aşamada yeniden kullanılabilir workflow'lar, kurumsal ölçekte paylaşılan şablonlar, güvenlik taramalarının akışa katılması ve akışların süre ile başarısızlık göstergeleriyle izlenmesi yer alır. Bu noktada konu bir araç bilgisinden çıkıp genel bir teslimat mühendisliği tasarımına dönüşür.

Bu beceriyi Mindset programında nerede çalışırsınız?

CI/CD Pipeline Tasarımı (GitHub Actions) programının modül başlıkları bu yolu izler: GitHub Actions temelleri, sürekli entegrasyon boru hattı, konteyner ve imaj yönetimi, çok ortamlı dağıtım stratejileri, yeniden kullanılabilir iş akışları, güvenlik ve uyumluluk entegrasyonu ile gözlemlenebilirlik ve optimizasyon.