Jenkins & Sürekli Entegrasyon Nedir?

Sürekli Entegrasyon (CI), DevOps’un çeşitli DevOps aşamalarını entegre etmek için kullanılan en önemli parçasıdır. Jenkins en ünlü Sürekli Entegrasyon aracıdır. Jenkins’in popülaritesinin arkasındaki nedeni merak ettiğinizi ve Jenkins’i öğrenmenin kolay olup olmadığını merak ettiğinizi biliyorum. Bu “Jenkins nedir?” blogunu okuduktan sonra, tüm sorularınızın yanıtlanacağından oldukça eminim.

Jenkins’in ne olduğunu basit kelimelerle anlayalım.

Jenkins nedir ve neden kullanıyoruz?
Jenkins, Sürekli Entegrasyon amacıyla oluşturulmuş eklentilerle, Java ile yazılmış açık kaynaklı bir otomasyon aracıdır. Jenkins, yazılım projelerinizi sürekli olarak oluşturmak ve test etmek için kullanılır, bu da geliştiricilerin değişiklikleri projeye entegre etmesini ve kullanıcıların yeni bir yapı elde etmesini kolaylaştırır. Ayrıca, çok sayıda test ve dağıtım teknolojisiyle bütünleşerek yazılımınızı sürekli olarak teslim etmenize olanak tanır.

Jenkins ile kuruluşlar, otomasyon yoluyla yazılım geliştirme sürecini hızlandırabilir. Jenkins, derleme, belgeleme, test etme, paketleme, aşama, devreye alma, statik analiz ve çok daha fazlası dahil olmak üzere her türlü geliştirme yaşam döngüsü sürecini entegre eder.

Jenkins, eklentilerin yardımıyla Sürekli Entegrasyona ulaşır. Eklentiler, Çeşitli DevOps aşamalarının entegrasyonuna izin verir. Belirli bir aracı entegre etmek istiyorsanız, o araç için eklentileri yüklemeniz gerekir. Örneğin Git, Maven 2 projesi, Amazon EC2, HTML yayıncısı vb.

Jenkins’in avantajları şunları içerir:

• Büyük topluluk desteğine sahip açık kaynaklı bir araçtır.
• Yüklemek kolaydır.
• İşinizi kolaylaştırmak için 1000’den fazla eklentiye sahiptir.
• Bir eklenti yoksa, onu kodlayabilir ve toplulukla paylaşabilirsiniz.
• Ücretsizdir.
• Java ile oluşturulmuştur ve bu nedenle tüm büyük platformlara taşınabilir.
• Jenkins’i diğer Sürekli Entegrasyon aracından ayıran bazı şeyler var. Gelin o noktalara bir göz atalım.

Jenkins Özellikleri
Jenkins’i diğer Sürekli Entegrasyon araçlarından daha iyi yapan bazı gerçekler şunlardır:

Benimseme: Jenkins, dünya çapında 147.000’den fazla aktif kurulum ve 1 milyondan fazla kullanıcı ile oldukça yaygındır.
Eklentiler: Jenkins, geliştirme, test etme ve dağıtım araçlarının çoğuyla entegre olmasına izin veren 1.000’den fazla eklentiyle birbirine bağlıdır.
Yukarıdaki noktalardan Jenkins’in küresel olarak çok yüksek bir talebin olduğu açıktır. Jenkins’e dalmadan önce Sürekli Entegrasyonun ne olduğunu ve neden tanıtıldığını bilmek önemlidir.

Sürekli Entegrasyon Nedir?
Sürekli Entegrasyon, geliştiricilerin günde birkaç kez veya daha sık olarak paylaşılan bir havuzdaki kaynak kodunda değişiklik yapmalarını gerektiren bir geliştirme uygulamasıdır. Depoda yapılan her taahhüt daha sonra oluşturulur. Bu, ekiplerin sorunları erken tespit etmesini sağlar. Bunun dışında, Sürekli Entegrasyon aracına bağlı olarak, derleme uygulamasını test sunucusuna dağıtmak, ilgili ekiplere derleme ve test sonuçlarını sağlamak vb. gibi başka işlevler de vardır.

Bir kullanım örneği ile önemini anlayalım.

Sürekli Entegrasyon Örneği: Nokia
Hepinizin hayatınızın bir noktasında Nokia telefonları kullanmış olduğunuzdan oldukça eminim. Nokia’daki bir yazılım ürünü geliştirme projesinde Nightly builds adı verilen bir süreç vardı. Gecelik derlemeler, Sürekli Entegrasyonun öncülü olarak düşünülebilir. Bu, otomatik bir sistemin gün boyunca paylaşılan depoya eklenen kodu her gece çekmesi ve bu kodu oluşturması anlamına gelir. Fikir, Sürekli Entegrasyona oldukça benzer, ancak geceleri oluşturulan kod oldukça büyük olduğundan, hataların bulunması ve düzeltilmesi gerçek bir acıydı. Bu nedenle Nokia, Sürekli Entegrasyon’u (CI) benimsemiştir. Sonuç olarak, depodaki kaynak koduna yapılan her taahhüt oluşturuldu. Derleme sonucu kodda bir hata olduğunu gösteriyorsa, geliştiricilerin yalnızca bu belirli taahhüdü kontrol etmesi gerekir. Bu, yeni yazılımı yayınlamak için gereken süreyi önemli ölçüde azaltmıştır.

Şimdi Jenkins’in Sürekli Entegrasyona nasıl ulaştığını anlamanın doğru zamanı.

Jenkins ile Sürekli Entegrasyon
Uygulamanın tam kaynak kodunun oluşturulduğu ve ardından test için test sunucusuna yerleştirildiği bir senaryo hayal edelim. Yazılım geliştirmek için mükemmel bir yol gibi görünüyor, ancak bu işlemin birçok kusuru var. Bunları tek tek açıklamaya çalışacağım:

• Geliştiriciler, test sonuçları için eksiksiz yazılım geliştirilinceye kadar beklemek zorundadır.
• Test sonuçlarının birden fazla hata gösterme olasılığı yüksektir. Uygulamanın tüm kaynak kodunu kontrol etmeleri gerektiğinden geliştiricilerin bu hataları bulmaları zordu.
• Yazılım teslim sürecini yavaşlatır.
• Yazılım kalitesinin düşebileceği için kodlama veya mimari sorunlar, yapı hataları, test durumu ve dosya yayın yüklemeleri gibi şeylerle ilgili sürekli geri bildirim eksikti.
• Tüm süreç, sık arıza riskini artıran manuel işlemlerden oluşuyordu.

Yalnızca yazılım teslim sürecinin yavaşladığı değil, aynı zamanda yazılım kalitesinin de düştüğü, yukarıda belirtilen sorunlardan açıkça görülmektedir. Bu da müşteri memnuniyetsizliğine yol açmaktadır. Bu nedenle, böyle bir kaosun üstesinden gelmek için, geliştiricilerin kaynak kodunda yapılan her değişiklik için sürekli olarak bir yapıyı tetikleyebilecekleri ve test edebilecekleri bir sistemin var olmasına büyük bir ihtiyaç vardı. CI’nin amacı budur. Jenkins, mevcut en olgun CI aracıdır, bu yüzden Jenkins ile Sürekli Entegrasyonun yukarıdaki eksiklikleri nasıl aştığını görelim.

İlk önce size Jenkins ile Sürekli Entegrasyonun genel bir akış şemasını açıklayacağım, böylece kendini açıklayıcı hale gelecek, Jenkins yukarıdaki eksikliklerin üstesinden nasıl geliyor. Bu, Jenkins’in nasıl çalıştığını anlamanıza yardımcı olacaktır.

• İlk olarak, bir geliştirici kodu kaynak kod deposuna taahhüt eder. Bu arada Jenkins sunucusu, değişiklikler için düzenli aralıklarla depoyu kontrol eder.
• Bir taahhüt gerçekleştikten kısa bir süre sonra, Jenkins sunucusu kaynak kod deposunda meydana gelen değişiklikleri algılar. Jenkins bu değişiklikleri alacak ve yeni bir yapı hazırlamaya başlayacak.
• Oluşturma başarısız olursa, ilgili ekip bilgilendirilecektir.
• Derleme başarılı olursa, Jenkins yerleşik test sunucusunu dağıtır.

Testten sonra Jenkins bir geri bildirim oluşturur ve ardından geliştiricileri derleme ve test sonuçları hakkında bilgilendirir. Kaynak kodda yapılan değişiklikler için kaynak kod deposunu kontrol etmeye devam edecek ve tüm süreç tekrar etmeye devam edecek. Artık Jenkins’in geleneksel SDLC eksikliklerinin üstesinden nasıl geldiğini biliyorsunuz. Aşağıdaki tablo “Jenkins Öncesi ve Sonrası” arasındaki karşılaştırmayı göstermektedir.

Jenkins’ten önce ve sonra