Mikroservis Yazı Serisi 13 - Deployment Automation

    Selamün Aleyküm Arkadaşlar, 

    Serinin on üçüncü yazısında otomatik deployment süreçlerinden bahsetmeye çalışacağız. Önceki yazıda da bu konuya ufaktan değinmiştik. Şimdi ise daha detaylı bakmayı deneyeceğiz. Monolit yapıda olursa güzel olur dediğimiz yapı, mikroservislerde bu süreç zorunluluk haline geliyor. Mikroservis mimarisinin amaçlarından biri de gün içinde sık sık ve küçük deploy'lar yapabilmektir. Bunu yapmanın yolu da buradan geçmektedir. Hazırsak başlayalım.

    Monolit uygulamalarda manuel deployment zor olur diye belirtmiştik, bunu yapmanın farklı şekilleri var. IIS üzerinden dll kopyalarak yapan da var, FTP ile dosya atan da var, bu iş zor oluyor diyerek otomatik deployment (prod ortam için tetikleyerek olabilir, çünkü monolit yapı tek bir commit ile çalışmaz hale gelebilir) yapan da oluyor. Ancak mikroservis dünyasında bu bir seçenek olmaktan çıkıp zorunluluk haline gelmektedir.

    Konunun temelini CI (Continuous Integration) ve CD (Continuous Deployment/Delivery) süreçleri  oluşturur. Zaman zaman birbirlerine de karıştıkları oluyor. Yukarıda bahsettiğimiz kodun sık aralıklarla sürüm kontrol (Git gibi) versiyonlama sistemlerine gönderilmesine denilirken, CD ise bu kodun her zaman deploy edilmeye hazır bulunmasına denir.

    Bu sürecin bize ne gibi faydaları olur derseniz, kodu sık sık canlıya göndermek olabilecek problemlerin saptamasını hızlandırır. Ekipler arası kod entegrasyonu karmaşıklığı azalır. Testleriniz de varsa gönderilen kodu kontrol ettiği için kod kalitesini artırır. Bunların sağladığı yararlarla birlikte kod her zaman deploy edilmeye hazır bir halde olur. Geliştirilen işler hızlı bir şekilde canlıya çıkarak müşteriyi de memnun etmiş olursunuz, kendinizi de memnun etmiş olursunuz (sizleri bilmem ama yazdığım bir kod farklı sebeplerden bloklanıp uzun süre bekleyip canlıya gitmediğinde stres oluyorum :) )...

https://www.turing.com/kb/top-cicd-tools-you-should-learn-in-2022

    Peki bunları nasıl ayarlarız derseniz ilk akla gelen araç Jenkins olur herhalde. Açık kaynaklı, çok esnek her türlü taklayı atabileceğiniz bir araç, ancak konfigürasyon, yapılandırma gibi kısımları öğrenme açısından zor olabilir. Bununla ilgilenen bir ekibiniz yoksa bunu kullanmak yorabilir.

    Gitlab CI/CD ve Github Actions yine bu konularda sizlere yardımcı olan araçlardan. Bizler projeleri Github üzerinde tuttuğumuz için bizim için Github Actions kullanmak oldukça pratik bir durum oldu. Kendiniz de yeni bir akış oluşturmak istediğinizde size bir template sunuyor ve kolaylıkla konfigürasyonları yapılandırabiliyorsunuz. Daha sonra otomatik veya elle tetikleme veya farklı ortamlar için farklı süreçleri ele alabiliyorsunuz. Bunun dezavantajı ise yeterince esnek olmayabilir ve daha çok kendi repolarındaki projelere yöneliktir.

    Circle CI, TeamCity, Bamboo yine bilinen araçlardan. Bununla birlikte bulut tabanlı servislerin de kendi çözümleri bulunmaktadır. Azure DevOps, AWS CodePipeline de bunlara örnek çözümlerdir. 

    Özetle her bir çözümün kendine göre avantaj ve dezavantajları tabii ki vardır. Buradaki çözüm ekibiniz yetkinliklerine ve projenin isterlerine göre kendinize en uygun olanı aracı seçmeniz gerekmektedir.

    Yazıyı birer ayet-i kerime ve hadis-i şerif ile bitirelim.

"İş konusunda onlarla istişare et. Kararını verdiğin zaman ise artık Allah’a tevekkül et. Şüphesiz Allah, tevekkül edenleri sever." (Âl-i İmrân Suresi, 3:159)

"İşlerin en hayırlısı, az da olsa devamlı olanıdır." (Buhârî, Rikak 18; Müslim, Müsâfirîn 217)