Sürekli Entegrasyon, GitHub Eylemleri ve Sonar Cloud Hakkında Bilmeniz Gereken Her Şey

Sürekli Entegrasyon (CI) kavramıyla ilk kez Mozilla projesi başlatıldığında karşılaştım. Sürecin bir parçası olarak temel bir yapı sunucusunu içeriyordu ve bu o zamanlar devrim niteliğindeydi. Oluşturulması ve bağlanması 2 saat süren bir C++ projesini sürdürüyordum.

Projeye kötü kod uygulandığı için bileşik sorunlar yaratan temiz bir yapıdan nadiren geçtik.

O eski günlerden bu yana çok şey değişti. CI ürünleri her yerde ve Java geliştiricileri olarak, daha önce hiç olmadığı kadar zengin bir yetenek zenginliğinden yararlanıyoruz. Ama kendimi aşıyorum… Temel bilgilerle başlayalım.

Sürekli Entegrasyon, kod değişikliklerinin otomatik olarak oluşturulduğu ve sık ve tutarlı bir şekilde test edildiği bir yazılım geliştirme uygulamasıdır.

CI'nın amacı, entegrasyon sorunlarını mümkün olan en kısa sürede yakalayıp çözmek, böylece hataların ve diğer sorunların üretime sızma riskini azaltmaktır.

CI genellikle kod entegrasyonundan üretimde dağıtıma kadar tüm yazılım teslim sürecini otomatikleştirmeyi amaçlayan Sürekli Teslimat (CD) ile el ele gider.

CD'nin amacı, yeni sürümleri ve düzeltmeleri dağıtmak için gereken zamanı ve çabayı azaltarak ekiplerin müşterilere daha hızlı ve daha sık değer sunmasına olanak sağlamaktır.

CD ile CI testlerini geçen her kod değişikliği dağıtıma hazır olarak kabul edilir ve ekiplerin yeni sürümleri istedikleri zaman güvenle dağıtmalarına olanak tanır. Bu yazıda sürekli teslimattan bahsetmeyeceğim ancak tartışılacak çok şey olduğu için bu konuya geri döneceğim.

Konseptin büyük bir hayranıyım ama izlememiz gereken bazı şeyler var.

Sürekli Entegrasyon Araçları

Birçok güçlü sürekli entegrasyon aracı vardır. Yaygın olarak kullanılan bazı araçlar şunlardır:

• Jenkins : Jenkins, çeşitli programlama dillerini ve derleme araçlarını desteklemek için geniş bir eklenti ve entegrasyon yelpazesi sunan, en popüler CI araçlarından biridir. Açık kaynaklıdır ve yapı işlem hatlarını kurmak ve yönetmek için kullanıcı dostu bir arayüz sunar.

  
  

  Java ile yazılmıştır ve çoğu zaman benim "başvuracağım araç" olmuştur. Ancak yönetimi ve kurulumu bir acıdır. Biraz eksik olan kullanıcı deneyimini de temizleyen bazı "Hizmet olarak Jenkins" çözümleri var.

• Travis CI : Travis CI, GitHub ile iyi bir şekilde entegre olan bulut tabanlı bir CI aracıdır ve bu da onu GitHub tabanlı projeler için mükemmel bir seçim haline getirir. GitHub Eylemlerinden önce geldiği için GitHub'daki birçok açık kaynaklı proje için varsayılan haline geldi.

• CircleCI : CircleCI, çok çeşitli programlama dillerini ve oluşturma araçlarını destekleyen bulut tabanlı bir CI aracıdır. Kullanıcı dostu bir arayüz sunar, ancak en büyük avantajı yapım ve teslimat hızıdır.

• GitLab CI/CD : GitLab, yerleşik CI/CD özelliklerini içeren popüler bir kaynak kodu yönetim aracıdır. GitLab çözümü esnek ama basittir; GitLab alanının dışında bile endüstride bir miktar ilgi kazandı.

• Bitbucket Pipelines : Bitbucket Pipelines, Atlassian'ın kaynak kodu yönetim aracı olan Bitbucket ile sorunsuz bir şekilde bütünleşen bulut tabanlı bir CI aracıdır. Atlassian ürünü olduğundan kusursuz JIRA entegrasyonu ve son derece akıcı, kurumsal odaklı işlevsellik sağlar.

Birazdan değineceğimiz GitHub Eylemlerinden bahsetmediğime dikkat edin. CI araçlarını karşılaştırırken dikkate alınması gereken birkaç faktör vardır:

• Kullanım Kolaylığı: Bazı CI araçlarının basit bir kurulum süreci ve kullanıcı dostu arayüzü vardır; bu da geliştiricilerin başlamalarını ve derleme süreçlerini yönetmelerini kolaylaştırır.

• GitHub, GitLab ve Bitbucket gibi Kaynak Kodu Yönetimi (SCM) Araçlarıyla entegrasyon. Bu, ekiplerin derleme, test ve dağıtım süreçlerini otomatikleştirmesini kolaylaştırır.

• Farklı Programlama Dilleri ve Derleme Araçları Desteği: Farklı CI araçları, farklı programlama dillerini ve derleme araçlarını destekler; bu nedenle, geliştirme yığınınızla uyumlu bir araç seçmek önemlidir.

• Ölçeklenebilirlik: Bazı CI araçları, karmaşık yapı hatlarına sahip daha büyük kuruluşlar için daha uygunken diğerleri, daha basit ihtiyaçları olan daha küçük ekipler için daha uygundur.

• Maliyet: CI araçlarının maliyeti, ücretsiz ve açık kaynaktan pahalı olabilecek ticari araçlara kadar çeşitlilik gösterir; bu nedenle bütçenize uygun bir araç seçmeniz önemlidir.

• Özellikler: Farklı CI araçları, gerçek zamanlı derleme ve test sonuçları, paralel yapılar için destek ve yerleşik dağıtım yetenekleri gibi farklı özellikler sunar.

Genel olarak Jenkins, çok yönlülüğü ve kapsamlı eklenti kitaplığıyla tanınır ve bu da onu karmaşık yapı hatlarına sahip ekipler için popüler bir seçim haline getirir. Travis CI ve CircleCI, kullanım kolaylıkları ve popüler SCM araçlarıyla entegrasyonlarıyla tanınıyor ve bu da onları küçük ve orta ölçekli ekipler için iyi bir seçim haline getiriyor.

GitLab CI/CD, entegre CI/CD yetenekleri sunduğundan, kaynak kodu yönetimi için GitLab'ı kullanan ekipler için popüler bir seçimdir. Bitbucket Pipelines, platformla sorunsuz bir şekilde bütünleştiği için kaynak kodu yönetimi için Bitbucket kullanan ekipler için iyi bir seçimdir.

Bulut ve Şirket İçi Karşılaştırması

Aracıların barındırılması, bir CI çözümü seçerken dikkate alınması gereken önemli bir faktördür. Aracı barındırma için iki ana seçenek vardır: bulut tabanlı ve şirket içi.

• Bulut tabanlı : Travis CI, CircleCI, GitHub Actions ve Bitbucket Pipelines gibi bulut tabanlı CI çözümleri, aracıları buluttaki kendi sunucularında barındırır. Bu, temel altyapıyı yönetme konusunda endişelenmenize gerek olmadığı ve bulutun ölçeklenebilirliği ve güvenilirliğinden yararlanabileceğiniz anlamına gelir.

• Şirket içi : Jenkins gibi şirket içi CI çözümleri, aracıları kendi sunucularınızda barındırmanıza olanak tanır. Bu size temel altyapı üzerinde daha fazla kontrol sağlar ancak aynı zamanda sunucuları yönetmek ve bakımını yapmak için daha fazla çaba gerektirir.

Bir CI çözümü seçerken ekibinizin özel ihtiyaçlarını ve gereksinimlerini dikkate almak önemlidir.

Örneğin, büyük ve karmaşık bir yapı hattınız varsa, Jenkins gibi şirket içi bir çözüm daha iyi bir seçim olabilir çünkü temel altyapı üzerinde daha fazla kontrol sahibi olmanızı sağlar.

Öte yandan, basit ihtiyaçları olan küçük bir ekibiniz varsa, kurulumu ve yönetimi kolay olduğundan Travis CI gibi bulut tabanlı bir çözüm daha iyi bir seçim olabilir.

Aracı Durumu

Durumsallık, aracıların derlemeler arasında verilerini ve yapılandırmalarını koruyup korumayacağını belirler.

• Durum Bilgili Aracılar : Jenkins gibi bazı CI çözümleri, durum bilgisi olan aracılara izin verir; bu, aracıların derlemeler arasında verilerini ve yapılandırmalarını koruduğu anlamına gelir. Bu, bir veritabanı kullanırken veya uzun süren testler çalıştırırken olduğu gibi, derlemeler arasında verileri kalıcı hale getirmeniz gereken durumlar için kullanışlıdır.

• Durum Bilgisi Olmayan Aracılar : Travis CI gibi diğer CI çözümleri durum bilgisi olmayan aracılar kullanır; bu, aracıların her yapı için sıfırdan yeniden oluşturulduğu anlamına gelir. Bu, her yapı için temiz bir sayfa sağlar, ancak aynı zamanda kalıcı verileri ve yapılandırmaları veritabanı veya bulut depolama alanı gibi harici olarak yönetmeniz gerektiği anlamına da gelir.

En iyi yaklaşıma ilişkin CI savunucuları arasında canlı bir tartışma var. Durum bilgisi olmayan aracılar temiz ve çoğaltılması kolay bir ortam sağlar. Çoğu durumda bunları seçiyorum ve bunların daha iyi bir yaklaşım olduğunu düşünüyorum.

Vatansız temsilcilerin kurulumu daha yavaş olduğundan daha pahalı olabilir. Bulut kaynakları için ödeme yaptığımız için bu maliyet artabilir. Ancak bazı geliştiricilerin durum bilgisi olan aracıları tercih etmesinin ana nedeni, araştırma yeteneğidir.

Durum bilgisi olmayan bir aracıyla, bir CI süreci başarısız olduğunda genellikle günlükler dışında hiçbir araştırma yöntemiyle kalmazsınız.

Durum bilgisi olan bir aracıyla, makinede oturum açabilir ve işlemi verilen makinede manuel olarak çalıştırmayı deneyebiliriz. Başarısız olan bir konuyu yeniden üretebilir ve bu sayede içgörü kazanabiliriz.

Birlikte çalıştığım bir şirket, Azure'un durum bilgisi olan aracılara izin vermesi nedeniyle GitHub Eylemleri yerine Azure'u seçti. Başarısız bir CI sürecinde hata ayıklarken bu onlar için önemliydi.

Buna katılmıyorum ama bu kişisel bir görüş. Bir hatayı araştırmak için harcadığım zamandan daha fazlasını, kötü aracı temizleme sorununu gidermeye harcadığımı hissediyorum. Ancak bu kişisel bir deneyim ve bazı akıllı arkadaşlarım bu görüşe katılmıyor.

Tekrarlanabilir Yapılar

Tekrarlanabilir yapılar, ortamdan veya yapının gerçekleştirildiği zamandan bağımsız olarak, bir yapı her gerçekleştirildiğinde aynı yazılım yapıtlarını tam olarak üretme yeteneğini ifade eder.

DevOps açısından bakıldığında, tekrarlanabilir yapılara sahip olmak, yazılım dağıtımlarının tutarlı ve güvenilir olmasını sağlamak için çok önemlidir.

Aralıklı başarısızlıklar her yerde DevOps'un belasıdır ve takip edilmesi acı vericidir.

Ne yazık ki kolay bir düzeltme yok. Her ne kadar istesek de, makul karmaşıklığa sahip projelerde bazı düzensizlikler kendine yer buluyor. Bunu mümkün olduğu kadar en aza indirmek bizim görevimiz. Tekrarlanabilir yapıların önünde iki engelleyici vardır:

• Bağımlılıklar - Bağımlılıklar için belirli sürümleri kullanmazsak, küçük bir değişiklik bile yapımızı bozabilir.

• Kesintili Testler - Belirgin bir neden olmaksızın ara sıra başarısız olan testler kesinlikle en kötüsüdür.

Bağımlılıkları tanımlarken belirli sürümlere odaklanmamız gerekir. Pek çok sürüm oluşturma şeması var, ancak son on yılda standart üç rakamlı anlamsal sürüm oluşturma sektörü ele geçirdi.

Bu şema CI için son derece önemlidir çünkü kullanımı bir yapının tekrarlanabilirliğini önemli ölçüde etkileyebilir, örneğin maven ile şunları yapabiliriz:

 <dependency> <groupId>group</groupId> <artifactId>artifact</artifactId> <version>2.3.1</version> </dependency>

Bu çok spesifiktir ve tekrarlanabilirlik açısından mükemmeldir. Ancak bu, hızla güncelliğini yitirebilir. Sürüm numarasını, otomatik olarak geçerli sürümü alacak olan LATEST veya RELEASE ile değiştirebiliriz. Yapılar artık tekrarlanamayacağından bu kötü bir durumdur.

Ancak, sabit kodlanmış üç sayı yaklaşımı da sorunludur. Çoğu zaman bir yama sürümünün bir hataya yönelik bir güvenlik düzeltmesini temsil ettiği durumdur. Bu durumda, daha yeni sürümlere değil, en son küçük güncellemeye kadar güncelleme yapmak isteriz.

Örneğin, önceki durum için, 2.4.1 değil, 2.3.2 sürümünü dolaylı olarak kullanmak isterdim. Bu, küçük güvenlik güncellemeleri ve hatalar için bir miktar tekrarlanabilirliği ortadan kaldırır.

Ancak daha iyi bir yol , Maven Sürüm Eklentisini kullanmak ve düzenli aralıklarla mvn versions:use-latest-releases komutunu çağırmak olacaktır. Bu, projemizi güncel tutmak için sürümleri en son sürüme günceller.

Bu, tekrarlanabilir yapıların basit kısmıdır. Zorluk, kesikli testlerdedir. Bu o kadar yaygın bir sorun ki, bazı projeler "makul miktarda" başarısız test tanımlıyor ve bazı projeler başarısızlığı kabul etmeden önce yapıyı birden çok kez yeniden çalıştırıyor.

Test düzensizliğinin ana nedeni durum sızıntısıdır. Önceki bir testten kalan hafif yan etkiler nedeniyle testler başarısız olabilir. İdeal olarak, her testin ayrı ayrı çalışabilmesi için bir testin kendi kendine temizlenmesi gerekir.

Mükemmel bir dünyada, her testi tamamen izole edilmiş taze bir ortamda gerçekleştirirdik ancak bu pratik değildir. Bu, testlerin yürütülmesinin çok uzun süreceği ve CI süreci için çok fazla beklememiz gerektiği anlamına gelir.

Çeşitli izolasyon seviyelerinde testler yazabiliriz; Bazen tam izolasyona ihtiyaç duyarız ve test için bir konteyneri çalıştırmamız gerekebilir. Ancak çoğu zaman bunu yapmıyoruz ve hızdaki fark önemli.

Testlerden sonra temizlik yapmak çok zordur. Bazen veritabanı gibi harici araçlardan gelen durum sızıntıları, hatalı test hatasına neden olabilir. Başarısızlığın tekrarlanabilirliğini sağlamak için test senaryolarını tutarlı bir şekilde sıralamak yaygın bir uygulamadır; bu, yapının gelecekteki çalıştırmalarının aynı sırada yürütülmesini sağlar.

Bu çok tartışılan bir konudur. Bazı mühendisler bunun hatalı testleri teşvik ettiğine ve yalnızca rastgele bir test sırası ile keşfedebileceğimiz sorunları gizlediğine inanıyor. Deneyimlerime göre, bu gerçekten testlerde hatalar buldu, ancak kodda bulamadı.

Amacım mükemmel testler oluşturmak değil ve bu nedenle testleri alfabetik sıralama gibi tutarlı bir sırada çalıştırmayı tercih ediyorum.

Test başarısızlıklarının istatistiklerini tutmak önemlidir ve hiçbir zaman yeniden dene tuşuna basmayın. Sorunlu testleri ve bir başarısızlığın uygulanma sırasını takip ederek çoğu zaman sorunun kaynağını bulabiliriz.

Çoğu zaman, başarısızlığın temel nedeni önceki testteki hatalı temizlemeden kaynaklanır; bu nedenle sıralama ve tutarlılığı da önemlidir.

Geliştirici Deneyimi ve CI Performansı

Bir CI aracı değil, bir yazılım ürünü geliştirmek için buradayız. CI aracı süreci daha iyi hale getirmek için burada. Ne yazık ki, çoğu zaman CI aracıyla olan deneyim o kadar sinir bozucu oluyor ki, aslında kod yazmaktan çok lojistiğe daha fazla zaman harcıyoruz.

Değişikliklerimi birleştirebilmek için çoğu zaman günlerimi CI kontrolünden geçmeye çalışarak harcadım. Ne zaman yaklaşsam, başka bir geliştirici önce kendi değişikliklerini birleştiriyor ve benim yapımı bozuyordu.

Bu, özellikle ekip ölçeklendiğinde ve değişikliklerimizi birleştirmek yerine CI kuyruğunda daha fazla zaman harcadığımızda, mükemmel olmayan bir geliştirici deneyimine katkıda bulunur. Bu sorunları hafifletmek için yapabileceğimiz birçok şey var:

• Testlerdeki tekrarları azaltın - Aşırı test, kapsam araçlarıyla tespit edebildiğimiz yaygın bir semptomdur.

• Kesintili testlerin ortadan kaldırılması - Testleri silmenin veya devre dışı bırakmanın sorunlu olduğunu biliyorum. Bunu hafifçe yapmayın. Ancak kodunuzda hata ayıklamak yerine testte hata ayıklamaya daha fazla zaman ayırırsanız değeri tartışılabilir.

• CI süreci için ek veya daha hızlı makineler tahsis edin.

• CI sürecini paralelleştirin. Bazı yapı türlerini ve bazı testleri paralel hale getirebiliriz.

• Projeyi daha küçük projelere bölün; bunun mutlaka mikro hizmetler anlamına gelmediğine dikkat edin.

Sonuçta bu doğrudan geliştiricilerin üretkenliğine bağlıdır. Ancak bu tür optimizasyonlar için profil oluşturucularımız yok. Her seferinde ölçmek zorundayız; bu zahmetli olabilir.

GitHub Eylemleri

GitHub Actions, GitHub'da yerleşik bir sürekli entegrasyon/sürekli dağıtım (CI/CD) platformudur. Aracıların bir dereceye kadar kendi kendine barındırılmasına izin vermesine rağmen vatansızdır. Açık kaynaklı projeler için ücretsiz olması ve kapalı kaynaklı projeler için makul bir ücretsiz kotaya sahip olması nedeniyle buna odaklanıyorum.

Bu ürün, alanda nispeten yeni bir rakiptir ve daha önce bahsedilen diğer CI araçlarının çoğu kadar esnek değildir. Ancak GitHub ve durum bilgisi olmayan aracılarla derin entegrasyonu sayesinde geliştiriciler için oldukça kullanışlıdır.

GitHub Eylemlerini test etmek için yeni bir projeye ihtiyacımız var; bu durumda JHipster kullanarak burada görülen yapılandırmayla oluşturdum:

Burada GitHub Eylemlerinin kullanımını gösteren ayrı bir proje oluşturdum. Bunu herhangi bir projede takip edebileceğinize dikkat edin; Bu durumda maven talimatlarını dahil etmemize rağmen konsept çok basittir.

Proje oluşturulduktan sonra GitHub üzerinde proje sayfasını açıp eylemler sekmesine geçebiliriz.

Bunun gibi bir şey göreceğiz:

Sağ alt köşede Maven proje tipine sahip Java’yı görebiliriz. Bu türü seçtikten sonra burada gösterildiği gibi bir maven.yml dosyası oluşturmaya geçiyoruz:

Maalesef GitHub tarafından önerilen varsayılan maven.yml bir sorun içeriyor. Bu resimde gördüğümüz kod şudur:

 name: Java CI with Maven on: push: branches: [ "master" ] pull_request: branches: [ "master" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up JDK 11 uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' cache: maven - name: Build with Maven run: mvn -B package --file pom.xml # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive - name: Update dependency graph uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6

Son üç satır bağımlılık grafiğini günceller. Ancak bu özellik başarısız oluyor veya en azından benim için başarısız oldu. Bunları kaldırmak sorunu çözdü. Kodun geri kalanı standart YAML yapılandırmasıdır.

Kodun üst kısmına yakın olan pull_request ve push satırları, derlemelerin hem çekme isteğinde hem de ana makineye gönderimde çalışacağını bildirir. Bu, taahhütte bulunmadan önce testlerimizi bir çekme isteği üzerine çalıştırabileceğimiz anlamına gelir. Test başarısız olursa taahhütte bulunmayacağız.

Proje ayarlarında başarısız testlerle işleme izin vermeyebiliriz. YAML dosyasını kaydettikten sonra bir çekme isteği oluşturabiliriz ve sistem bizim için derleme işlemini çalıştıracaktır. Buna, maven'deki "paket" hedefi varsayılan olarak testleri çalıştırdığından testlerin yürütülmesi de dahildir.

Testleri başlatan kod, sonuna yakın "run" ile başlayan satırdadır. Bu etkili bir şekilde standart bir Unix komut satırıdır. Bazen bir kabuk betiği oluşturmak ve onu yalnızca CI sürecinden çalıştırmak mantıklı olabilir.

Bazen iyi bir kabuk betiği yazmak, tüm YAML dosyalarıyla ve çeşitli CI yığınlarının yapılandırma ayarlarıyla uğraşmaktan daha kolaydır.

Ayrıca gelecekte CI aracını değiştirmeyi seçersek daha taşınabilir olur. Burada maven mevcut ihtiyaçlarımız için yeterli olduğundan buna ihtiyacımız yok.

Başarılı çekme isteğini burada görebiliriz:

Bunu test etmek için “/api” uç noktasını “/myapi” olarak değiştirerek koda bir hata ekleyebiliriz. Bu, aşağıda gösterilen arızaya neden olur. Ayrıca taahhüdün yazarına gönderilen bir hata e-postasını da tetikler.

Böyle bir arıza oluştuğunda sağ taraftaki “Detaylar” linkine tıklayabiliriz. Bu bizi doğrudan burada gördüğünüz hata mesajına götürür:

Ne yazık ki, bu genellikle sorunun çözümünde yardım sağlamayan işe yaramaz bir mesajdır. Ancak yukarı kaydırmak, burada görüldüğü gibi bizim için genellikle uygun şekilde vurgulanan gerçek arızayı gösterecektir:

Çoğu zaman birden fazla hata olduğunu unutmayın, bu nedenle daha fazla yukarı kaydırmanın akıllıca olacağını unutmayın. Bu hatada, burada görebileceğiniz AccountResourceIT'in 394 satırındaki hatanın bir iddia olduğunu görebiliyoruz, satır numaralarının eşleşmediğini unutmayın. Bu durumda 394 satır yöntemin son satırıdır:

 @Test @Transactional void testActivateAccount() throws Exception { final String activationKey = "some activation key"; User user = new User(); user.setLogin("activate-account"); user.setEmail("[email protected]"); user.setPassword(RandomStringUtils.randomAlphanumeric(60)); user.setActivated(false); user.setActivationKey(activationKey); userRepository.saveAndFlush(user); restAccountMockMvc.perform(get("/api/activate?key={activationKey}", activationKey)).andExpect(status().isOk()); user = userRepository.findOneByLogin(user.getLogin()).orElse(null); assertThat(user.isActivated()).isTrue(); }

Bu, iddia çağrısının başarısız olduğu anlamına gelir. isActivated() false döndürdü ve testte başarısız oldu. Bu, geliştiricinin sorunu daraltmasına ve temel nedeni anlamasına yardımcı olacaktır.

Ötesine Geçmek

Daha önce de belirttiğimiz gibi CI, geliştirici üretkenliğiyle ilgilidir. Sadece derlemek ve test etmekten çok daha ileri gidebiliriz. Kodlama standartlarını uygulayabilir, kodu lintleyebilir, güvenlik açıklarını tespit edebilir ve çok daha fazlasını yapabiliriz.

Bu örnekte güçlü bir kod analiz aracı (linter) olan Sonar Cloud'u entegre edelim. Projenizdeki potansiyel hataları bulur ve kod kalitesini artırmanıza yardımcı olur.

SonarCloud, geliştiricilerin kod kalitesi, güvenlik ve bakım kolaylığı ile ilgili sorunları bulup düzeltmek için kodlarını sürekli olarak incelemelerine ve analiz etmelerine olanak tanıyan, SonarQube'un bulut tabanlı bir sürümüdür. Java, C#, JavaScript, Python ve daha fazlası gibi çeşitli programlama dillerini destekler.

SonarCloud, GitHub, GitLab, Bitbucket, Azure DevOps ve daha fazlası gibi popüler geliştirme araçlarıyla entegre olur. Geliştiriciler, kodlarının kalitesi hakkında gerçek zamanlı geri bildirim almak ve genel kod kalitesini iyileştirmek için SonarCloud'u kullanabilir.

Öte yandan SonarQube, yazılım geliştiricilere statik kod analiz araçları sağlayan açık kaynaklı bir platformdur. Kod kalitesinin bir özetini gösteren bir kontrol paneli sağlar ve geliştiricilerin kod kalitesi, güvenlik ve bakım kolaylığı ile ilgili sorunları belirleyip düzeltmelerine yardımcı olur.

Hem SonarCloud hem de SonarQube benzer işlevsellikler sağlar ancak SonarCloud bulut tabanlı bir hizmettir ve abonelik gerektirir; SonarQube ise şirket içi veya bulut sunucusuna kurulabilen açık kaynaklı bir platformdur.

Basitlik açısından SonarCloud'u kullanacağız ancak SonarQube gayet iyi çalışmalı. Başlamak için sonarcloud.io'ya gidip kaydoluyoruz. İdeal olarak GitHub hesabımızla. Daha sonra burada gösterildiği gibi Sonar Cloud tarafından izlenmek üzere bir depo ekleme seçeneği sunulur:

Yeni sayfayı analiz et seçeneğini seçtiğimizde GitHub depomuza erişim yetkisi vermemiz gerekiyor. Bir sonraki adım, Sonar Cloud'a eklemek istediğimiz projeleri burada gösterildiği gibi seçiyoruz:

Seçim yapıp kurulum sürecine ilerledikten sonra analiz yöntemini seçmemiz gerekiyor. GitHub Actions kullandığımız için aşağıdaki aşamada bu seçeneği burada görüldüğü gibi seçmemiz gerekiyor:

Bu ayarlandıktan sonra aşağıdaki görüntüde görüldüğü gibi Sonar Cloud sihirbazında son aşamaya giriyoruz. Kopyalayabileceğimiz bir jeton alıyoruz (görüntüde giriş 2 bulanık) ve bunu kısa süre içinde kullanacağız.

Ayrıca, "Maven" etiketli düğmeye tıkladığınızda görünen, maven ile kullanılacak varsayılan talimatların da olduğuna dikkat edin.

GitHub'da projeye geri dönerek proje ayarları sekmesine geçebiliriz (üst menüdeki hesap ayarlarıyla karıştırılmamalıdır). Burada, burada gösterildiği gibi “Sırlar ve değişkenler”i seçiyoruz:

Bu bölümde, burada görebileceğiniz gibi, özellikle SonarCloud'dan kopyaladığımız SONAR_TOKEN anahtarını ve değerini içeren yeni bir repository secret ekleyebiliriz:

GitHub Depo Sırları, geliştiricilerin, depo tarafından kullanılan çeşitli üçüncü taraf hizmetlere veya platformlara erişimi doğrulamak ve yetkilendirmek için gereken API anahtarları, belirteçler ve parolalar gibi GitHub deposuyla ilişkili hassas bilgileri güvenli bir şekilde saklamasına olanak tanıyan bir özelliktir. .

GitHub Repository Secrets'ın arkasındaki konsept, bilgileri kod veya yapılandırma dosyalarında herkese açık hale getirmek zorunda kalmadan, gizli bilgileri yönetmenin ve paylaşmanın güvenli ve kullanışlı bir yolunu sağlamaktır.

Geliştiriciler, sırları kullanarak hassas bilgileri kod tabanından ayrı tutabilir ve bir güvenlik ihlali veya yetkisiz erişim durumunda açığa çıkmasını veya tehlikeye atılmasını önleyebilir.

GitHub Deposu Sırları güvenli bir şekilde saklanır ve yalnızca depoya erişim izni verilen yetkili kullanıcılar tarafından erişilebilir. Gizli diziler, iş akışlarında, eylemlerde ve depoyla ilişkili diğer komut dosyalarında kullanılabilir.

Bunlar, koda ortam değişkenleri olarak aktarılabilir, böylece kod, sırlara güvenli ve güvenilir bir şekilde erişebilir ve bunları kullanabilir.

Genel olarak GitHub Depo Sırları, geliştiricilerin bir depoyla ilişkili gizli bilgileri yönetmeleri ve korumaları için basit ve etkili bir yol sağlayarak projenin ve işlediği verilerin güvenliğini ve bütünlüğünü sağlamaya yardımcı olur.

Artık bunu projeye entegre etmemiz gerekiyor. Öncelikle bu iki satırı pom.xml dosyasına eklememiz gerekiyor. Kuruluş adını kendi adınızla eşleşecek şekilde güncellemeniz gerektiğine dikkat edin. Bunlar XML'deki bölüme girmelidir:

 <sonar.organization>shai-almog</sonar.organization> <sonar.host.url>https://sonarcloud.io</sonar.host.url>

Oluşturduğumuz JHipster projesinin zaten SonarQube desteğine sahip olduğuna dikkat edin, bu kodun çalışması için bu desteğin pom dosyasından kaldırılması gerekir .

Bundan sonra maven.yml dosyasının “Build with Maven” kısmını aşağıdaki versiyonla değiştirebiliriz:

 - name: Build with Maven env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=shai-almog_HelloJHipster package

Bunu yaptığımızda SonarCloud, burada gösterildiği gibi sisteme birleştirilen her çekme isteği için rapor sağlayacaktır:

Hataların, güvenlik açıklarının, kokuların ve güvenlik sorunlarının bir listesini içeren bir rapor görebiliriz. Bu sorunların her birine tıklamak bizi şunun gibi bir şeye yönlendirir:

Sorunun tam olarak neden sorun olduğunu, nasıl düzeltileceğini ve daha fazlasını açıklayan sekmelerimizin olduğuna dikkat edin. Bu, ekipteki en değerli kod incelemecilerden biri olarak hizmet veren son derece güçlü bir araçtır.

Daha önce gördüğümüz iki ilginç unsur daha haber ve tekrar raporlarıdır. SonarCloud, testlerin %80 kod kapsamına sahip olmasını bekler (bir çekme isteğinde kodun %80'ini tetikler), bu yüksektir ve ayarlarda yapılandırılabilir.

Ayrıca Kendinizi Tekrar Etmeyin (DRY) ilkesinin ihlal edildiğini gösterebilecek yinelenen koda da işaret eder.

Nihayet

CI, projenizin akışını iyileştirmeye yönelik birçok fırsatın bulunduğu büyük bir konudur. Hata tespitini otomatik hale getirebiliriz. Eser üretimini, otomatik teslimatı ve çok daha fazlasını kolaylaştırın. Ancak benim naçizane görüşüme göre CI'nın arkasındaki temel prensip geliştirici deneyimidir.

Hayatımızı kolaylaştırmak için burada.

Kötü yapıldığında CI süreci bu harika aracı bir kabusa dönüştürebilir. Testleri geçmek boşuna bir egzersiz haline gelir. Sonunda birleşene kadar tekrar tekrar deneriz. Yavaş ve kalabalık kuyruklardan dolayı saatlerce bir araya gelmeyi bekliyoruz.

Yardımcı olması gereken bu araç baş düşmanımız haline geliyor. Durum böyle olmamalı. CI hayatımızı kolaylaştırmalı, tam tersi değil.