Devops etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

DevOps mühendisliğine geçmek isteyen bir yazılım mühendisi için izlemesi gereken adımlar

Ali Turgut BOZKURT

Temmuz 12, 2024 Hiç yorum yok

Devops

Bitbucket Pipeline ile Kubernetes Üzerinde Microservice Deployment: Spring Cloud, Docker ve Test Süreçleri

Ali Turgut BOZKURT

Temmuz 08, 2024 Hiç yorum yok

Tabii, Maven kullanarak aynı senaryoyu anlatabilirim. Maven, Java projeleri için popüler bir build ve proje yönetim aracıdır. İşte 3 mikroservisten oluşan, Docker'ize edilmiş ve Kubernetes üzerine deploy edilen bir Spring Cloud uygulaması için Maven tabanlı bir Bitbucket pipeline örneği:

1. Pipeline Tanımı:

Projenizin kök dizininde `bitbucket-pipelines.yml` dosyasını oluşturun ve aşağıdaki gibi tanımlayın:

```yaml

image: maven:3.8.4-openjdk-11

pipelines:

default:

- step:

caches:

- maven

script:

- mvn clean install

- step:

caches:

- maven

script:

- mvn checkstyle:check pmd:check

- step:

services:

- docker

script:

- mvn package dockerfile:build -Ddockerfile.skip=false

- step:

services:

- docker

script:

- echo $DOCKER_PASSWORD | docker login -u $DOCKER_USERNAME --password-stdin

- mvn dockerfile:push -Ddockerfile.skip=false

- step:

script:

- pipe: atlassian/kubectl-run:1.1.2

variables:

KUBE_CONFIG: $KUBE_CONFIG

KUBECTL_COMMAND: 'apply'

RESOURCE_PATH: 'k8s/'

```

2. Adımların Açıklaması:

a. Build and Test:

- `mvn clean install` komutu projeyi derler, testleri çalıştırır ve JAR dosyalarını oluşturur.

b. Code Quality Check:

- `mvn checkstyle:check pmd:check` komutu Checkstyle ve PMD araçlarını kullanarak kod kalitesi kontrolü yapar.

c. Build Docker Images:

- `mvn package dockerfile:build` komutu, her mikroservis için Docker imajlarını oluşturur. Bu adım için `dockerfile-maven-plugin` kullanılıyor varsayılmıştır.

d. Push to Docker Registry:

- `mvn dockerfile:push` komutu, oluşturulan Docker imajlarını registry'ye gönderir.

e. Deploy to Kubernetes:

- Kubernetes cluster'ına dağıtım yapar.

3. Maven Konfigürasyonu:

Her mikroservis için `pom.xml` dosyasında şu eklentileri tanımlamanız gerekebilir:

```xml

<build>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-maven-plugin</artifactId>

</plugin>

<groupId>com.spotify</groupId>

<artifactId>dockerfile-maven-plugin</artifactId>

<repository>${docker.image.prefix}/${project.artifactId}</repository>

<tag>${project.version}</tag>

<JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>

</buildArgs>

</configuration>

</plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-checkstyle-plugin</artifactId>

</plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-pmd-plugin</artifactId>

</plugin>

</plugins>

</build>

```

4. Ek Öneriler:

- Çoklu modül projesi için, kök `pom.xml` dosyasında tüm mikroservisleri modül olarak tanımlayın.

- Her mikroservis için ayrı bir Dockerfile oluşturun.

- SonarQube gibi daha kapsamlı kod analiz araçları ekleyebilirsiniz (`mvn sonar:sonar` komutu ile).

- Versiyonlama için Maven Release Plugin kullanabilirsiniz.

- Test coverage raporları için JaCoCo gibi araçlar ekleyebilirsiniz.

Bu Maven tabanlı pipeline, kod değişikliklerini otomatik olarak derler, test eder, kod kalitesini kontrol eder, Docker imajları oluşturur ve bunları Kubernetes cluster'ına dağıtır.

Belirli bir adım hakkında daha detaylı bilgi isterseniz veya başka sorularınız varsa, lütfen belirtin.

Tabii, bu önerileri daha detaylı açıklayabilirim:

1. SonarQube Entegrasyonu:

SonarQube, kod kalitesi ve güvenlik açıklarını analiz etmek için kullanılan güçlü bir araçtır. Maven projenize SonarQube eklemek için:

a. `pom.xml` dosyanıza şu eklentiyi ekleyin:

```xml

<groupId>org.sonarsource.scanner.maven</groupId>

<artifactId>sonar-maven-plugin</artifactId>

</plugin>

```

b. Bitbucket pipeline'ınıza yeni bir adım ekleyin:

```yaml

- step:

script:

- mvn sonar:sonar

-Dsonar.projectKey=your_project_key

-Dsonar.host.url=$SONAR_URL

-Dsonar.login=$SONAR_TOKEN

```

c. Bitbucket repository ayarlarında `SONAR_URL` ve `SONAR_TOKEN` ortam değişkenlerini tanımlayın.

2. Maven Release Plugin:

Maven Release Plugin, projenizin sürüm numarasını otomatik olarak yönetmenize ve release'leri etiketlemenize yardımcı olur.

a. `pom.xml` dosyanıza şu eklentiyi ekleyin:

```xml

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-release-plugin</artifactId>

<tagNameFormat>v@{project.version}</tagNameFormat>

<releaseProfiles>release</releaseProfiles>

</configuration>

</plugin>

```

b. Release işlemi için Bitbucket pipeline'ınıza yeni bir dal (branch) ekleyin:

```yaml

pipelines:

branches:

release/*:

- step:

script:

- mvn release:prepare release:perform

```

Bu, `release/*` ile başlayan dallarda otomatik olarak release işlemi gerçekleştirecektir.

3. JaCoCo ile Test Coverage:

JaCoCo, Java kod coverage aracıdır ve test kapsama raporları oluşturmanıza yardımcı olur.

a. `pom.xml` dosyanıza şu eklentiyi ekleyin:

```xml

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

<goals>

<goal>prepare-agent</goal>

</goals>

</execution>

<id>report</id>

<goals>

<goal>report</goal>

</goals>

</execution>

</executions>

</plugin>

```

b. Bitbucket pipeline'ınızın "Build and Test" adımını güncelleyin:

```yaml

- step:

caches:

- maven

script:

- mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install

- mvn org.jacoco:jacoco-maven-plugin:report

artifacts:

- target/site/jacoco/**

```

Bu konfigürasyon, test coverage raporlarını oluşturacak ve bunları pipeline artifact'ları olarak saklayacaktır.

Bu araçları entegre etmek, kod kalitenizi artırmanıza, sürüm yönetiminizi iyileştirmenize ve test coverage'ınızı görselleştirmenize yardımcı olacaktır. Her bir aracın konfigürasyonu projenizin ihtiyaçlarına göre daha da özelleştirilebilir.

Bu konularda daha fazla detay veya başka sorularınız varsa, lütfen sormaktan çekinmeyin.

Devops main

DORA (DevOps Research and Assessment) metrikleri

Ali Turgut BOZKURT

Temmuz 02, 2024 Hiç yorum yok

DORA (DevOps Research and Assessment) metrikleri, yazılım teslimatı ve operasyonel performansı ölçmek için DevOps araştırma grubu tarafından geliştirilmiş dört temel metrikten oluşur. Bu metrikler, yazılım geliştirme ve dağıtım süreçlerinin etkinliğini ve verimliliğini değerlendirmek için kullanılır. DORA metrikleri şunlardır:

Dağıtım Sıklığı (Deployment Frequency): Yazılımın üretim ortamına ne sıklıkta dağıtıldığını ölçer. Daha sık dağıtım, sürekli entegrasyon ve sürekli dağıtım (CI/CD) uygulamalarının başarılı bir şekilde uygulandığını gösterir.
Değişiklik Teslim Süresi (Lead Time for Changes): Kod değişikliklerinin geliştirilmesinden üretim ortamına dağıtılmasına kadar geçen süredir. Bu sürenin kısa olması, ekiplerin hızlı ve verimli bir şekilde çalıştığını gösterir.
Başarısızlık Oranı (Change Failure Rate): Üretim ortamına yapılan değişikliklerin başarısızlık oranını ölçer. Bu metrik, yazılım kalitesini ve değişikliklerin risk düzeyini değerlendirir. Düşük bir başarısızlık oranı, iyi test süreçleri ve kaliteli kod yazımını gösterir.
İyileşme Süresi (Mean Time to Restore): Bir başarısızlık veya kesinti durumunda, hizmetin yeniden çalışır hale getirilmesi için geçen ortalama süredir. Kısa bir iyileşme süresi, etkili sorun çözme ve hızlı yanıt verme kabiliyetini gösterir.

Bu metrikler, yazılım geliştirme ve dağıtım süreçlerinin performansını objektif bir şekilde ölçmeye yardımcı olur ve ekiplerin verimliliğini artırmak için iyileştirme alanlarını belirlemelerine olanak tanır. DORA metrikleri, yüksek performanslı yazılım ekiplerinin başarıyı nasıl tanımladığını ve bu başarıyı nasıl elde ettiğini anlamak için kullanılır.

Örnek bir senaryo üzerinden DORA metriklerini açıklayalım.

Senaryo: Bir e-ticaret platformu geliştiren bir yazılım ekibi

1. Dağıtım Sıklığı (Deployment Frequency)

Senaryo: E-ticaret platformu ekibi, her iki haftada bir düzenli olarak yeni özellikler ve hata düzeltmeleri içeren güncellemeler yayınlıyor.

Ölçüm: Ekibin dağıtım sıklığı iki haftada bir olarak belirlenir. Daha sık dağıtım yapabiliyorlarsa, bu metrik daha yüksek olacaktır ve bu, CI/CD süreçlerinin etkin bir şekilde uygulandığını gösterir.

2. Değişiklik Teslim Süresi (Lead Time for Changes)

Senaryo: Ekibin bir ürün sayfasında küçük bir tasarım değişikliği yapması gerekti. Bu değişikliğin kodlanması, test edilmesi ve üretim ortamına dağıtılması toplamda üç gün sürdü.

Ölçüm: Bu üç günlük süre, değişiklik teslim süresi olarak kaydedilir. Daha kısa bir teslim süresi, ekibin değişiklikleri hızlı bir şekilde dağıtabildiğini ve hızlı geri bildirim alarak müşteri memnuniyetini artırabileceğini gösterir.

3. Başarısızlık Oranı (Change Failure Rate)

Senaryo: Son bir ayda ekip 20 dağıtım gerçekleştirdi ve bu dağıtımlardan 2'si hatalıydı, bu hatalar üretim ortamında sorunlara yol açtı.

Ölçüm: Başarısızlık oranı = (Başarısız dağıtım sayısı / Toplam dağıtım sayısı) = 2 / 20 = %10. Düşük bir başarısızlık oranı, ekibin iyi test süreçlerine ve kaliteli kod yazımına sahip olduğunu gösterir.

4. İyileşme Süresi (Mean Time to Restore)

Senaryo: Bir dağıtım sırasında, müşterilerin ödeme yapmasını engelleyen bir hata ortaya çıktı. Ekip bu hatayı 1 saat içinde tespit edip düzeltti.

Ölçüm: Bu durumda, iyileşme süresi 1 saat olarak belirlenir. Kısa bir iyileşme süresi, ekibin hızlı sorun çözme yeteneğine ve etkin izleme sistemlerine sahip olduğunu gösterir.

Senaryo Özet

Dağıtım Sıklığı: Ekip iki haftada bir dağıtım yapıyor.
Değişiklik Teslim Süresi: Küçük bir değişiklik üç günde tamamlanıyor.
Başarısızlık Oranı: Dağıtımların %10'u başarısız oluyor.
İyileşme Süresi: Hatalar 1 saat içinde düzeltiliyor.

Bu senaryo, bir yazılım ekibinin DORA metrikleri üzerinden performansını nasıl değerlendirebileceğini ve bu metrikleri iyileştirmek için hangi alanlarda çalışmaları gerektiğini göstermektedir. Ekibin dağıtım sıklığını artırmak, teslim süresini kısaltmak, başarısızlık oranını düşürmek ve iyileşme süresini azaltmak için sürekli iyileştirmeler yapması gerekecektir.

Devops Test

Sistem ve Tarayıcı Testlerini Hızlandırma: Çoklu Makinelerde Sharding Yöntemi

Ali Turgut BOZKURT

Temmuz 01, 2024 Hiç yorum yok

Sistem-tarayıcı testlerini birden fazla makinede sharding yaparak çalıştırmak, test sürecini hızlandırmak ve daha verimli hale getirmek için kullanılan bir yöntemdir. İşte bu yöntemi adım adım nasıl uygulayabileceğinizi anlatan bir rehber:

1. Sharding Nedir?

Sharding, test yükünü birden fazla makineye bölerek test süresini azaltmayı hedefleyen bir tekniktir. Her bir shard (parça), testlerin bir alt kümesini çalıştırır.

2. Ortamın Hazırlanması

Test Ortamı: Tüm makinelerin aynı test ortamına erişebildiğinden emin olun. Bu, aynı yazılım versiyonlarının ve bağımlılıkların yüklü olduğu anlamına gelir.
Ağ: Makineler arasında hızlı ve güvenilir bir ağ bağlantısı olmalıdır.

3. Testlerin Shard'lara Bölünmesi

Testlerin Dağıtılması: Test setini makul büyüklükteki shard'lara bölün. Bu bölme işlemi manuel olarak yapılabilir veya bir araç kullanarak otomatikleştirilebilir.
Adil Dağılım: Shard'lar arasında adil bir iş yükü dağılımı sağlanmalıdır. Bu, her bir shard'ın yaklaşık aynı sürede tamamlanmasını sağlar.

4. Araçlar ve Çerçeveler

Test Çerçeveleri: Sharding'i destekleyen test çerçevelerini kullanın. Örneğin, Selenium Grid, TestNG ve JUnit gibi araçlar sharding işlemini destekler.
CI/CD Entegrasyonu: Jenkins, GitLab CI/CD gibi CI/CD araçları genellikle sharding desteğine sahiptir ve bu işlemi otomatikleştirebilir.

5. Shard'ların Çalıştırılması

Makinelerin Hazırlanması: Her bir makinede gerekli test altyapısının kurulu olduğundan emin olun.
Testlerin Çalıştırılması: Testler, belirlenen shard'lara göre makinelere dağıtılarak çalıştırılır. Örneğin, Selenium Grid kullanıyorsanız, her bir makine bir node olarak yapılandırılır ve testler hub üzerinden shard'lara dağıtılır.

6. Sonuçların Toplanması ve Raporlanması

Sonuçların Toplanması: Tüm shard'ların test sonuçları merkezi bir yerde toplanır. Bu, sonuçların analiz edilmesini ve raporlanmasını kolaylaştırır.
Raporlama: Test sonuçları birleştirilerek kapsamlı bir test raporu oluşturulur. Bu rapor, tüm shard'ların sonuçlarını içermelidir.

Adım Adım Örnek:

Varsayalım ki 1000 adet test case'iniz var ve bunları 4 shard'a bölmek istiyorsunuz:

Test Dağılımı: 1000 testi 250'şerlik 4 shard'a böldünüz.
Makinelerin Hazırlanması: 4 makine hazırladınız ve her bir makineye gerekli yazılımları kurdunuz.
Shard Konfigürasyonu: Her bir makineye 250 test case'i içeren bir shard atadınız.
Testlerin Çalıştırılması: CI/CD aracı kullanarak testlerinizi her bir makinede paralel olarak çalıştırdınız.
Sonuçların Toplanması: Her bir makineden test sonuçlarını merkezi bir sunucuya topladınız.
Raporlama: Merkezi sunucuda tüm sonuçları birleştirerek kapsamlı bir test raporu oluşturdunuz.

Bu süreç, test süresini önemli ölçüde azaltır ve daha hızlı geri bildirim almanızı sağlar. Ayrıca, testlerin paralel çalışması, kaynak kullanımını optimize ederek daha verimli bir test süreci sağlar.

Apache Maven Devops Junit multithreading Test

Junit5'de birim testleri ve entegrasyon testleri nasıl paralel çalıştırılır?

Ali Turgut BOZKURT

Temmuz 01, 2024 Hiç yorum yok

JUnit 5'de birim testlerini ve entegrasyon testlerini paralel çalıştırmak için aşağıdaki adımları izleyebilirsiniz:

Maven veya Gradle Yapılandırması

JUnit 5'de paralel test çalıştırma özelliklerini kullanabilmek için Maven veya Gradle yapılandırmanızı güncellemeniz gerekebilir.

Maven

Maven kullanıyorsanız, maven-surefire-plugin ve maven-failsafe-plugin eklentilerini yapılandırmanız gerekiyor.

pom.xml:

xml
<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M5</version>
        <configuration>
          <parallel>methods</parallel>
          <useUnlimitedThreads>true</useUnlimitedThreads>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <version>3.0.0-M5</version>
        <configuration>
          <parallel>methods</parallel>
          <useUnlimitedThreads>true</useUnlimitedThreads>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>integration-test</goal>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Gradle

Gradle kullanıyorsanız, test ve integrationTest görevlerini paralel çalışacak şekilde yapılandırabilirsiniz.

build.gradle:

groovy
plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
}

test {
    useJUnitPlatform()
    maxParallelForks = Runtime.runtime.availableProcessors()
}

task integrationTest(type: Test) {
    useJUnitPlatform()
    shouldRunAfter test
    maxParallelForks = Runtime.runtime.availableProcessors()
    testClassesDirs = sourceSets.integrationTest.output.classesDirs
    classpath = sourceSets.integrationTest.runtimeClasspath
}

sourceSets {
    integrationTest {
        compileClasspath += sourceSets.main.output + sourceSets.test.output
        runtimeClasspath += sourceSets.main.output + sourceSets.test.output
    }
}

configurations {
    integrationTestImplementation.extendsFrom testImplementation
    integrationTestRuntimeOnly.extendsFrom testRuntimeOnly
}

JUnit 5 Konfigürasyonu

JUnit Platform Properties

JUnit 5'de paralel çalıştırma ayarlarını junit-platform.properties dosyasında yapabilirsiniz.

src/test/resources/junit-platform.properties:

properties
junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent
junit.jupiter.execution.parallel.config.strategy = dynamic

Bu ayarlar, JUnit 5 testlerini paralel olarak çalıştırmak için gerekli konfigürasyonları sağlar.

Testlerin Ayrılması

Birim testleri ve entegrasyon testlerini ayırmak için genellikle farklı paketler veya adlandırma kuralları kullanılır.

Birim testleri için src/test/java dizinini kullanabilirsiniz.
Entegrasyon testleri için src/integrationTest/java gibi ayrı bir dizin oluşturabilirsiniz.

Bu yapılandırmalarla birlikte JUnit 5 testlerini paralel olarak çalıştırabilir ve test süresini kısaltabilirsiniz.

Apache Maven Devops Test

Maven'de Hızlı Test Optimizasyonu: Erken Başarısızlık ile Test Sürecinizi Nasıl Hızlandırırsınız?

Ali Turgut BOZKURT

Temmuz 01, 2024 Hiç yorum yok

Maven'de önce hızlı testleri çalıştırmak ve erkenden fail alarak test sürecini hızlandırmak için testlerinizi gruplara ayırabilir ve bu grupları farklı Maven profilleri altında çalıştırabilirsiniz. Genellikle, hızlı testler unit olarak, daha uzun süren testler ise integration olarak etiketlenir. Bu şekilde, önce hızlı testleri çalıştırabilir ve bu testlerden herhangi biri başarısız olursa süreci durdurabilirsiniz.

İşte Maven yapılandırmasını bu amaca yönelik olarak nasıl ayarlayabileceğinizin bir örneği:

Adım 1: Testleri Gruplara Ayırma

Testlerinizi gruplara ayırmak için JUnit veya TestNG kullanabilirsiniz. Örneğin, JUnit 4 kullanıyorsanız, testlerinizi şu şekilde gruplandırabilirsiniz:

Hızlı Test (Unit Test)

java
import org.junit.experimental.categories.Category;
import org.junit.Test;

@Category(UnitTest.class)
public class MyUnitTest {
    @Test
    public void testSomethingQuick() {
        // Hızlı test kodu
    }
}

Yavaş Test (Integration Test)

java
import org.junit.experimental.categories.Category;
import org.junit.Test;

@Category(IntegrationTest.class)
public class MyIntegrationTest {
    @Test
    public void testSomethingSlow() {
        // Yavaş test kodu
    }
}

Adım 2: Maven Profilleri Oluşturma

pom.xml dosyanızda profilleri tanımlayarak bu test gruplarını çalıştırabilirsiniz.

xml
<project>
  ...
  <profiles>
    <!-- Hızlı testler için profil -->
    <profile>
      <id>fast-tests</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.0.0-M5</version>
            <configuration>
              <includes>
                <include>**/*Test.class</include>
              </includes>
              <excludedGroups>IntegrationTest</excludedGroups>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>

    <!-- Yavaş testler için profil -->
    <profile>
      <id>slow-tests</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-failsafe-plugin</artifactId>
            <version>3.0.0-M5</version>
            <executions>
              <execution>
                <goals>
                  <goal>integration-test</goal>
                  <goal>verify</goal>
                </goals>
                <configuration>
                  <groups>IntegrationTest</groups>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>

Adım 3: Testleri Çalıştırma

Önce hızlı testleri çalıştırmak için aşağıdaki komutu kullanabilirsiniz:

sh
mvn clean test -Pfast-tests

Eğer hızlı testler geçerse, yavaş testleri çalıştırmak için aşağıdaki komutu kullanabilirsiniz:

sh
mvn verify -Pslow-tests

Bu şekilde, önce hızlı testleri çalıştırarak erken bir hata tespit ederseniz tüm süreci durdurabilirsiniz, bu da test sürecinizi hızlandıracaktır.

Devops Test

CI/CD sürecinde test optimizasyonu ve performansını artırmak için stratejiler

Ali Turgut BOZKURT

Temmuz 01, 2024 Hiç yorum yok

CI/CD sürecinde test optimizasyonu ve performansını artırmak için aşağıdaki stratejileri kullanabilirsiniz:

Hızlı Test Çalıştırma ve Yavaş Test Paketlerini Hızlandırma:
- Test sürecinin başında hızlı çalışan testleri çalıştırarak erken geri bildirim alın.
- Yavaş test paketlerini paralel ve parçalı yürütme teknikleriyle hızlandırarak toplam test süresini kısaltın.
Test Piramidi Kullanımı
Test piramidi, yazılım test stratejisinde farklı test seviyelerinin doğru dengesini sağlamaya yönelik bir rehberdir. Test piramidi, birim testleri, entegrasyon testleri ve sistem testleri gibi farklı test seviyelerinin uygun miktarda ve oranda kullanılmasını teşvik eder. İşte test piramidinin nasıl kullanılacağına dair detaylar:
1. Birim Testleri:
- Tanım: Kodun küçük parçalarını (örneğin, fonksiyonlar, metodlar) izole bir şekilde test eder.
- Amaç: Her birim test, belirli bir fonksiyonun veya metodun beklenen şekilde çalıştığını doğrular.
- Özellikler:
  - Hızlı çalışır.
  - İzole bir ortamda yürütülür, yani bağımlılıklar minimum düzeydedir.
  - Genellikle düşük maliyetlidir ve hızlı geri bildirim sağlar.
- Örnek: Bir hesaplama fonksiyonunun doğru sonuçları verdiğini test etmek.
2. Entegrasyon Testleri:
- Tanım: Farklı bileşenlerin birlikte çalışma şeklini test eder.
- Amaç: Birim testlerinde ayrı ayrı doğrulanan bileşenlerin birlikte doğru çalıştığını ve entegre edildiklerinde beklenen sonuçları verdiğini doğrular.
- Özellikler:
  - Birkaç bağımlılığı içerir ve bunların entegrasyonunu test eder.
  - Birim testlerine göre daha yavaş çalışabilir.
  - Orta düzeyde maliyetlidir ve daha geniş kapsamlı geri bildirim sağlar.
- Örnek: Bir veri erişim katmanının bir veritabanı ile doğru şekilde etkileşimde bulunduğunu test etmek.
3. Sistem Testleri:
- Tanım: Tüm sistemin uçtan uca işleyişini test eder.
- Amaç: Uygulamanın son kullanıcı perspektifinden beklendiği gibi çalıştığını doğrular.
- Özellikler:
  - Tüm sistemin gerçek bir ortamda çalıştırılmasını içerir.
  - En yavaş test türüdür ve en pahalı olabilir.
  - Çok sayıda bağımlılığı içerir.
  - Kullanıcı hikayeleri veya iş gereksinimlerine göre yapılır.
- Örnek: Bir kullanıcı kaydının sistem üzerinden tamamlanmasını ve sonuçlarının doğru şekilde gösterildiğini test etmek.
Test Piramidi'nin Uygulanması
Test piramidini doğru bir şekilde uygulamak için aşağıdaki adımları izleyebilirsiniz:
1. Birim Testlerini Önceliklendirin:
  - Kodun her küçük parçası için kapsamlı birim testleri yazın.
  - Birim testleri yazarken bağımlılıkları izole edin ve mocking kullanın.
2. Entegrasyon Testlerini Dengeli Kullanın:
  - Kritik bileşenlerin entegrasyonunu test eden yeterli sayıda entegrasyon testi yazın.
  - Entegrasyon testlerinde, birim testlerinde izole edilen bileşenlerin birlikte nasıl çalıştığını doğrulayın.
3. Sistem Testlerini Minimize Edin ve Optimize Edin:
  - Sistemin ana fonksiyonlarını kapsayan sistem testleri yazın.
  - Sistem testlerini genellikle otomatikleştirin ve düzenli olarak çalıştırın, ancak daha az sayıda olmasına özen gösterin.
Sonuç
Test piramidi, yazılım projelerinde kalite güvencesini sağlamak için testlerin hangi seviyede ve ne miktarda yapılması gerektiğine dair bir yol haritası sunar. Birim testleri temel oluştururken, entegrasyon testleri ve sistem testleri piramidin üst katmanlarını tamamlar. Bu sayede daha hızlı, güvenilir ve kapsamlı bir test süreci sağlanır.
Test Kapsamı Ölçümü ve Uygun Oranı Koruma:
- Test kapsamı ölçümleriyle (örneğin, kod kapsamı, işlevsel kapsam) hangi alanların yeterince test edilip edilmediğini belirleyin.
- Belirlenen uygun test oranına ulaşmak ve bu oranı korumak için düzenli olarak test kapsamı ölçümlerini değerlendirin ve iyileştirin.
Paralel ve Parçalanmış Yürütme:
- Testleri paralel ve parçalara bölerek çalıştırmak, özellikle büyük ve yavaş test paketleri için test süresini önemli ölçüde azaltır.
- Bu yöntemi kullanarak, aynı anda birden fazla test yürütülür ve daha hızlı geri bildirim sağlanır.
Paralel ve Parçalı Yürütmenin Uygulanabilirliği ve Kullanımı:
- Paralel ve parçalı yürütmenin uygulanabilir olup olmadığını belirlemek için testlerin bağımlılıklarını ve birbirleriyle olan etkileşimlerini analiz edin.
- Bu analiz sonrasında, bağımsız çalışabilecek testleri belirleyerek paralel yürütmeyi başlatın.
- Testlerin farklı ortamlarda veya farklı veri setleriyle bağımsız olarak çalışabilmesini sağlamak için gerekli düzenlemeleri yapın.

Bu stratejiler, CI/CD sürecinde testlerin daha etkili ve hızlı bir şekilde yürütülmesine yardımcı olacaktır. Testlerin doğru oranlarda ve paralel olarak yürütülmesi, yazılım geliştirme sürecinin hızlanmasını ve kalite güvencesinin artırılmasını sağlar.

Devops Test

CI/CD Test Sorunları: Gürültü, Yanlış Sonuçlar ve Çözüm Stratejileri

Ali Turgut BOZKURT

Temmuz 01, 2024 Hiç yorum yok

CI/CD (Continuous Integration/Continuous Deployment) süreçlerinde testlerdeki gürültü ve zararlı sonuçlar, yazılım kalitesini ve dağıtım sürecini olumsuz etkileyebilir. İşte bu süreçlerde karşılaşılabilecek bazı yaygın sorunlar ve bunların etkileri:

Gürültü (Noise)

Yanlış Pozitifler (False Positives):
- Testler başarısız olmasa bile hatalı olarak başarısız olarak raporlanır.
- Geliştiricilerin gereksiz yere hata aramasına neden olur ve zaman kaybına yol açar.
Yanlış Negatifler (False Negatives):
- Gerçek hatalar gözden kaçabilir çünkü testler hataları tespit edemez.
- Hatalı kodun üretime geçmesine neden olabilir.
Flickering Tests:
- Bazen geçen bazen başarısız olan testlerdir.
- Kararsız testler, güvenilirliği zedeler ve CI/CD sürecinin aksamasına neden olabilir.
Çevresel Gürültü (Environmental Noise):
- Testlerin çalıştığı ortamda (örneğin, test makineleri arasındaki farklılıklar) kaynaklanan değişkenlikler.
- Konsol logları veya diğer test çıktılarındaki gereksiz bilgiler, önemli hataları gözden kaçırmanıza neden olabilir.

Zararlı Sonuçlar (Harmful Effects)

Yanıltıcı Başarı/Başarısızlık:
- Testlerin yanıltıcı bir şekilde başarılı veya başarısız olması, geliştiricilerin yanlış kararlar almasına neden olabilir.
- Yanlış sonuçlar, güveni azaltır ve süreçlerin verimliliğini düşürür.
Zaman ve Kaynak İsrafı:
- Gürültü ve yanıltıcı sonuçlarla başa çıkmak için gereksiz zaman harcanır.
- Testlerin tekrar tekrar çalıştırılması gerekebilir, bu da kaynak israfına yol açar.
Dağıtımın Gecikmesi:
- Yanlış negatifler veya kararsız testler nedeniyle, hataları düzeltmek ve testleri stabilize etmek zaman alabilir.
- Bu da yazılımın planlanan zamanda dağıtılamamasına yol açar.
Güven Kaybı:
- Geliştiriciler testlerin doğruluğuna güvenmediğinde, CI/CD sürecine olan güven azalır.
- Geliştiriciler testleri atlayabilir veya CI/CD'yi devre dışı bırakabilir, bu da yazılım kalitesini düşürür.

Çözüm Önerileri

Testlerin Stabilizasyonu:
- Flickering testlerin nedenlerini belirleyip çözmek.
- Testlerin çalıştığı çevresel değişkenleri minimize etmek.
Gürültünün Azaltılması:
- Test sonuçlarını ve logları optimize etmek.
- Gereksiz bilgileri filtrelemek.
Test Kapsamını ve Kalitesini Artırmak:
- Yanlış negatifleri azaltmak için test kapsamını genişletmek.
- Yanlış pozitifleri önlemek için test senaryolarını iyileştirmek.
Sürekli İzleme ve Geri Bildirim:
- Test sonuçlarını sürekli izlemek ve geliştiricilere hızlı geri bildirim sağlamak.
- Testlerin kalitesini artırmak için düzenli gözden geçirme ve güncellemeler yapmak.

Bu önlemler, CI/CD süreçlerinde testlerdeki gürültüyü ve zararlı sonuçları en aza indirerek, yazılım kalitesini ve süreç verimliliğini artırabilir.

Gürültülerden kurtulmak için yeni özelliklere ara verip testlere odaklanmak, doğru bir yaklaşım olabilir. Bu strateji, mevcut problemlerin çözülmesine ve CI/CD süreçlerinin daha stabil hale gelmesine yardımcı olabilir. İşte bu yaklaşımın bazı avantajları ve uygulanabilirliği:

Avantajları

Test Stabilizasyonu:
- Yeni özelliklerin eklenmesi durdurulduğunda, mevcut kod tabanında daha fazla odaklanılabilir.
- Flickering testlerin nedenleri daha iyi anlaşılır ve çözülebilir.
Sorunların Daha Hızlı Tespiti ve Çözümü:
- Geliştirici ekibi tamamen testlere ve mevcut sorunlara odaklanarak, hataları daha hızlı tespit edip düzeltebilir.
- Sürekli testlerin geçmesi sağlanarak, güvenilir bir CI/CD süreci oluşturulabilir.
Kalite Artışı:
- Test kapsamını genişleterek ve test senaryolarını iyileştirerek, yazılım kalitesi artırılabilir.
- Yanlış pozitif ve yanlış negatif test sonuçları minimize edilebilir.
Uzun Vadeli Verimlilik:
- Testlerin ve CI/CD süreçlerinin güvenilirliği sağlandığında, uzun vadede daha az sorun yaşanır.
- Yeni özellikler eklendiğinde, test süreçlerinin güvenilir olması, entegrasyon hatalarını azaltır.

Uygulanabilirliği

Planlama: Bu tür bir strateji, iyi bir planlama gerektirir. Ekip, hangi sorunların öncelikli olduğuna karar vererek, bir eylem planı oluşturmalıdır.
Zamanlama: Özellikle projede kritik bir dönem değilse, bu tür bir ara vermek daha kolay olabilir. Ancak, kritik dönemlerde bile bu strateji uzun vadede fayda sağlayabilir.
Takım Uyumu: Tüm geliştirici ekibinin bu yaklaşıma uyum sağlaması ve testlere odaklanması önemlidir. Ekip içi iletişim ve iş birliği artırılmalıdır.
Sürekli İyileştirme: Bu dönemde elde edilen bulgular ve yapılan iyileştirmeler, sürekli bir süreç haline getirilmelidir. Böylece, yeni özellikler eklenmeye devam ettiğinde, bu test iyileştirmeleri sürdürülebilir hale gelir.

Uygulama Önerileri

Test Envanteri Gözden Geçirme:
- Mevcut testlerin kapsamını ve kalitesini değerlendirin.
- Eksik veya hatalı testleri belirleyin ve iyileştirin.
Test Otomasyonunu Artırma:
- Manuel testlerin otomatikleştirilmesi için çalışmalar yapın.
- CI/CD süreçlerinde otomatik testlerin daha etkili kullanılmasını sağlayın.
Sorunların Kök Neden Analizi:
- Yanlış pozitif veya negatif testlerin kök nedenlerini belirleyin.
- Bu nedenleri ortadan kaldırmak için gerekli düzenlemeleri yapın.
Ekip Eğitimi ve Bilgilendirme:
- Tüm ekip üyelerinin test süreçlerine ve kalite güvence prensiplerine hakim olmasını sağlayın.
- Düzenli eğitimler ve bilgilendirme toplantıları düzenleyin.

Bu strateji, kısa vadede bazı yeni özelliklerin gecikmesine neden olabilir, ancak uzun vadede yazılım kalitesini ve CI/CD süreçlerinin güvenilirliğini artırarak, genel verimliliği ve müşteri memnuniyetini artırabilir.

Devops main

Yazılım Şirketlerinde CI/CD Eksikliğinin Önemli Sonuçları: Verimlilik ve Kalite Nasıl Etkilenir?

Ali Turgut BOZKURT

Haziran 21, 2024 Hiç yorum yok

CI/CD (Continuous Integration/Continuous Deployment) kullanmayan bir yazılım şirketinde çeşitli sorunlar ortaya çıkabilir. Bu sorunlar genellikle geliştirme, test ve dağıtım süreçlerinde etkin olmayan süreçlerden kaynaklanır. İşte bu sorunlardan bazıları:

Gecikmiş Entegrasyon:
- Geliştiriciler, kodlarını uzun süre ayrı dallarda tutabilir ve bu dalları birleştirmek zor ve zaman alıcı hale gelebilir.
- Entegrasyon sürecinde çok sayıda çatışma yaşanabilir.
Hataların Geç Tespit Edilmesi:
- Hatalar erken tespit edilemediği için, bu hatalar üretim ortamına kadar taşınabilir.
- Hataların bulunması ve düzeltilmesi daha maliyetli ve zaman alıcı hale gelir.
Manuel Test Süreçleri:
- Manuel testler zaman alıcıdır ve insan hatalarına açıktır.
- Otomatik testlerin olmaması, regresyon testlerini zorlaştırır ve yazılımın kalitesini düşürür.
Dağıtım Süreçlerinde Sorunlar:
- Dağıtımların manuel yapılması, hatalara ve gecikmelere yol açabilir.
- Otomatik dağıtım süreçlerinin olmaması, her dağıtımın farklı ortamlarda tutarsız çalışmasına neden olabilir.
Düşük Kod Kalitesi:
- Otomatik kod inceleme araçları kullanılmadığı için, kod kalitesi düşük olabilir.
- Kod standartlarına uyum zorlaşabilir.
Geri Bildirim Döngüsünün Uzaması:
- Geliştiriciler, kodlarının nasıl çalıştığını görmek için uzun süre bekleyebilir.
- Bu, geliştirme sürecini yavaşlatır ve motivasyonu düşürebilir.
Yüksek Bakım Maliyetleri:
- Kod tabanı büyüdükçe, hataların bulunması ve düzeltilmesi daha zor hale gelir.
- Teknik borç birikir ve bu da bakım maliyetlerini artırır.
Üretim Sorunları:
- Üretim ortamında beklenmedik sorunlar ortaya çıkabilir.
- Acil durum düzeltmeleri ve güncellemeleri daha zor ve riskli hale gelir.
Verimsiz Geliştirme Süreçleri:
- Geliştiriciler, kodlarının diğer parçalarla nasıl çalışacağını görmek için uzun süre bekleyebilir.
- Bu, geliştirme sürecini yavaşlatır ve takımın genel verimliliğini düşürür.
Zayıf İşbirliği ve İletişim:
- Geliştiriciler arasında zayıf işbirliği ve iletişim, entegrasyon süreçlerini daha zor ve karmaşık hale getirebilir.
- Takım içi bilgi paylaşımı ve işbirliği zorlaşabilir.

Bu sorunlar, yazılım geliştirme süreçlerinin yavaşlamasına, maliyetlerin artmasına ve yazılım kalitesinin düşmesine yol açabilir. Bu nedenle, CI/CD süreçlerinin benimsenmesi, yazılım geliştirme süreçlerini daha verimli, hatasız ve hızlı hale getirebilir.

Tabii ki, örnek bir senaryo üzerinden CI/CD kullanmayan bir yazılım şirketinde oluşabilecek sorunları detaylandıralım:

Senaryo:

Bir e-ticaret platformu geliştiren bir yazılım şirketinde çalışıyorsunuz. Şirket, CI/CD süreçlerini kullanmıyor ve manuel entegrasyon ve dağıtım süreçlerine güveniyor.

1. Gecikmiş Entegrasyon:

Durum: Geliştirici Ali, yeni bir özellik olan “İndirimli Ürünler” sayfasını geliştirmeye başlar. Aynı zamanda, geliştirici Ayşe de ödeme sayfasında bazı iyileştirmeler yapmaktadır. Her iki geliştirici de haftalarca kendi dallarında çalışır ve bu süre boyunca kodlarını ana dal ile birleştirmezler.

Sorun: Ali ve Ayşe’nin kodlarını ana dala entegre etmeleri gerektiğinde, bir dizi çatışma ortaya çıkar. Kodlar birbirini etkiler ve entegre etmek saatler, hatta günler alır. Bu süreçte ekip büyük bir zaman kaybı yaşar ve planlanan teslim tarihi gecikir.

2. Hataların Geç Tespit Edilmesi:

Durum: Yeni özellikler geliştirilip manuel olarak test edilir. Ancak bazı köşe durumlar gözden kaçar ve bu hatalar test aşamasında fark edilmez.

Sorun: Bu hatalar, kullanıcıların platformu kullanırken karşılaştığı ve platformun güvenilirliğini düşüren ciddi problemler haline gelir. Kullanıcılar, ödeme yaparken sorunlar yaşar ve bu durum müşteri memnuniyetsizliğine yol açar.

3. Manuel Test Süreçleri:

Durum: Her büyük güncellemeden sonra, test ekibi tüm sistemi manuel olarak test etmek zorundadır. Bu süreç, birkaç gün sürebilir.

Sorun: Manuel testler zaman alıcı ve hataya açık olduğu için bazı önemli hatalar gözden kaçabilir. Ayrıca, test ekibinin sürekli olarak manuel test yapmak zorunda kalması, onların verimliliğini ve moralini düşürür.

4. Dağıtım Süreçlerinde Sorunlar:

Durum: Yeni bir sürüm üretim ortamına manuel olarak dağıtılır. Dağıtım sırasında beklenmedik sorunlar ortaya çıkar.

Sorun: Dağıtım sırasında yapılan bir hata, sitenin saatlerce erişilemez olmasına neden olur. Bu durum, şirketin itibarını zedeler ve finansal kayıplara yol açar.

5. Düşük Kod Kalitesi:

Durum: Kod inceleme süreçleri manuel olarak yapılır ve her geliştiricinin yazdığı kod düzenli olarak kontrol edilmez.

Sorun: Kod kalitesi düştüğü için yazılımda teknik borç birikir. Bu borç, uzun vadede yazılımın bakımını zorlaştırır ve geliştirme sürecini yavaşlatır.

6. Geri Bildirim Döngüsünün Uzaması:

Durum: Geliştiriciler, yazdıkları kodun nasıl çalıştığını görmek için manuel test sonuçlarını bekler.

Sorun: Geri bildirim döngüsü uzar ve geliştiriciler, kodlarının doğru çalışıp çalışmadığını görmek için uzun süre beklemek zorunda kalır. Bu da geliştirme sürecini yavaşlatır ve motivasyonu düşürür.

Çözüm: CI/CD

Bu sorunları çözmek için CI/CD süreçlerini benimsemek kritik önem taşır. Otomatik entegrasyon ve dağıtım süreçleri, kod entegrasyonunu sorunsuz hale getirir, hataları erken tespit eder, manuel test yükünü azaltır ve dağıtım süreçlerini güvenilir ve hızlı hale getirir. Bu sayede, yazılım geliştirme süreçleri daha verimli, hızlı ve kaliteli olur.

Devops Jenkins

Jenkins Full Reher

Ali Turgut BOZKURT

Haziran 04, 2024 Hiç yorum yok

Jenkins, yazılım projeleri için sürekli entegrasyon ve teslimat süreçlerini otomatikleştirmeye yardımcı olan açık kaynaklı bir araçtır. Jenkins'in temel özelliklerini ve kullanımını anlatan bir giriş yapalım.

Jenkins'in Temel Özellikleri

Otomasyon: Jenkins, yazılım geliştirme süreçlerini otomatikleştirir. Kodun her yeni versiyonu için testleri çalıştırabilir, derlemeler yapabilir ve dağıtımları gerçekleştirebilir.
Eklenti Desteği: Jenkins, geniş bir eklenti ekosistemine sahiptir. Bu eklentiler sayesinde Jenkins'in işlevselliği artırılabilir.
Kolay Kurulum ve Yapılandırma: Jenkins, kurulum ve yapılandırma açısından kullanıcı dostudur. Web tabanlı arayüzü ile kolayca yapılandırılabilir.
Dağıtık Yapı: Jenkins, iş yükünü dağıtık bir şekilde yönetebilir. Master-Slave mimarisi sayesinde, farklı makinelerde farklı işler paralel olarak çalıştırılabilir.
Entegre Edilebilirlik: Jenkins, farklı versiyon kontrol sistemleri (Git, Subversion vb.), derleme araçları (Maven, Gradle vb.) ve test çerçeveleri (JUnit, TestNG vb.) ile entegre edilebilir.

Jenkins Kurulumu

Ön Koşullar

Java Development Kit (JDK) kurulu olmalıdır.

Adımlar

Jenkins'i İndirin ve Kurun:
- Jenkins'in resmi sitesinden kurulum dosyasını indirin.
- İndirme tamamlandıktan sonra, kurulum dosyasını çalıştırın ve talimatları izleyin.
Jenkins'i Başlatın:
- Jenkins'i başlatmak için terminal veya komut istemcisinde aşağıdaki komutu çalıştırın:
```
sh
java -jar jenkins.war
```
- Bu komut Jenkins'i varsayılan olarak 8080 portunda başlatacaktır.
Web Arayüzüne Erişim:
- Tarayıcınızı açın ve http://localhost:8080 adresine gidin.
- İlk girişte, Jenkins kurulum sihirbazı bir yönetici parolası ister. Bu parola, Jenkins kurulum dosyasının yer aldığı dizinde bulunan initialAdminPassword dosyasından alınabilir.
Eklentileri Yükleyin:
- Kurulum sihirbazı, gerekli eklentileri yüklemenizi sağlayacaktır. "Suggested plugins" seçeneğini seçerek önerilen eklentileri yükleyebilirsiniz.
Kullanıcı Hesabı Oluşturun:
- Jenkins, yönetici kullanıcı hesabı oluşturmanızı isteyecektir. Bu adımı tamamladıktan sonra Jenkins'in ana arayüzüne erişebilirsiniz.

İlk Pipeline (Boru Hattı) Oluşturma

Yeni Proje Oluşturun:
- Jenkins ana sayfasında "Yeni Öğe" düğmesine tıklayın.
- Proje adı girin ve "Pipeline" seçeneğini seçin.

Pipeline Yapılandırması:

Proje yapılandırma sayfasında, "Pipeline" sekmesine gidin.

Pipeline betiğini tanımlamak için "Pipeline script" alanına aşağıdaki örnek betiği ekleyin:

groovy
pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                // Derleme adımları burada
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
                // Test adımları burada
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
                // Dağıtım adımları burada
            }
        }
    }
}

Kaydedin ve Çalıştırın:
- Yapılandırmayı kaydedin ve projeyi çalıştırmak için "Build Now" düğmesine tıklayın.
- Çalıştırma durumu ve sonuçlarını "Build History" ve "Console Output" bölümlerinden takip edebilirsiniz.

Bu temel bilgilerle Jenkins'i kurabilir ve basit bir pipeline oluşturabilirsiniz. İhtiyaçlarınıza göre daha karmaşık yapılandırmalar ve entegrasyonlar ekleyerek Jenkins'i verimli bir şekilde kullanabilirsiniz. Herhangi bir sorunuz olursa, yardımcı olmaktan memnuniyet duyarım!

Jenkins ile Daha İleri Seviye Kullanım

Jenkinsfile ile Pipeline Tanımlama

Bir Jenkins pipeline'ını kod olarak tanımlamak, projeyi daha taşınabilir ve sürümlenebilir hale getirir. Bu dosyaya Jenkinsfile denir ve genellikle projenizin kök dizininde yer alır.

Örnek Jenkinsfile

groovy
pipeline {
    agent any
    
    environment {
        // Çevresel değişkenler burada tanımlanabilir
        APP_ENV = 'development'
    }

    stages {
        stage('Checkout') {
            steps {
                // Kaynak kodunun versiyon kontrol sisteminden çekilmesi
                checkout scm
            }
        }
        stage('Build') {
            steps {
                script {
                    // Derleme komutları
                    sh 'mvn clean install'
                }
            }
        }
        stage('Test') {
            steps {
                script {
                    // Test komutları
                    sh 'mvn test'
                }
            }
        }
        stage('Deploy') {
            steps {
                script {
                    // Dağıtım komutları
                    sh 'scp target/myapp.jar user@server:/path/to/deploy'
                }
            }
        }
    }

    post {
        always {
            // Her koşulda çalışacak adımlar
            echo 'Pipeline tamamlandı'
        }
        success {
            // Başarılı olursa çalışacak adımlar
            mail to: 'team@example.com',
                 subject: "Build Success",
                 body: "The build was successful."
        }
        failure {
            // Başarısız olursa çalışacak adımlar
            mail to: 'team@example.com',
                 subject: "Build Failed",
                 body: "The build failed. Please check the Jenkins logs."
        }
    }
}

Jenkins'in En Popüler Eklentileri

Jenkins'in işlevselliğini genişletmek için birçok eklenti mevcuttur. İşte en popüler eklentilerden bazıları:

Git Plugin: Jenkins'in Git ile entegre olmasını sağlar. Bu eklenti, Git depolarını kontrol edebilir ve kod değişikliklerini izleyebilir.
GitHub Plugin: GitHub ile entegrasyonu sağlar. GitHub webhook'ları ile Jenkins job'larını tetikleyebilir.
Pipeline Plugin: Pipeline tanımları ve yönetimi için gerekli araçları sağlar.
Blue Ocean: Jenkins için modern bir kullanıcı arayüzü sunar, pipeline'ları görsel olarak yönetmenizi sağlar.
Docker Plugin: Jenkins'in Docker konteynerleri içinde job'lar çalıştırmasını sağlar.
Slack Notification Plugin: Jenkins job sonuçlarını Slack kanallarına bildirmek için kullanılır.
JUnit Plugin: JUnit test sonuçlarını Jenkins üzerinde raporlamak için kullanılır.

Jenkins Master-Slave Mimarisi

Jenkins, dağıtık yapı desteği sayesinde büyük projeleri daha verimli bir şekilde yönetebilir. Bu mimaride, Jenkins master ve slave (agent) makineleri kullanılır.

Master: Jenkins ana sunucusu olarak görev yapar. Kullanıcı arayüzü, job tanımlamaları ve merkezi yönetim işlevlerini yerine getirir.
Slave (Agent): Master tarafından yönetilen ve job'ları çalıştıran makineler. Slavelar, master'dan iş yükünü alarak paralel işlemler gerçekleştirebilir.

Slave (Agent) Ekleme

Yönetici Paneline Erişim: Jenkins ana sayfasından "Manage Jenkins" sekmesine gidin.
Yeni Slave Tanımlama: "Manage Nodes and Clouds" sekmesine gidin ve "New Node" seçeneğine tıklayın.
Node Bilgileri: Node adını girin ve "Permanent Agent" seçeneğini seçin.
Yapılandırma: Node yapılandırma sayfasında, uzaktan bağlantı yöntemini (SSH, JNLP vb.) ve diğer gerekli bilgileri girin.
Kaydet ve Başlat: Yapılandırmayı kaydedin ve node'u başlatın.

İleri Seviye Pipeline Özellikleri

Paralel İşlemler

Pipeline'lar içinde paralel işlemler tanımlayarak, işlemleri aynı anda çalıştırabilirsiniz.

Örnek Paralel İşlem Tanımı

groovy
pipeline {
    agent any

    stages {
        stage('Parallel Stage') {
            parallel {
                stage('Unit Tests') {
                    steps {
                        sh 'mvn test'
                    }
                }
                stage('Integration Tests') {
                    steps {
                        sh 'mvn verify'
                    }
                }
            }
        }
    }
}

Koşullu Adımlar

Koşullu adımlar ile belirli koşullara göre pipeline adımlarını çalıştırabilirsiniz.

Örnek Koşullu Adım Tanımı

groovy
pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                script {
                    if (env.BRANCH_NAME == 'main') {
                        sh 'mvn clean deploy'
                    } else {
                        sh 'mvn clean package'
                    }
                }
            }
        }
    }
}

Jenkins'te Güvenlik

Jenkins'in güvenliğini sağlamak, yetkisiz erişim ve saldırılara karşı koruma sağlamak için önemlidir.

Kullanıcı Erişimi ve Rolleri: Jenkins'te kullanıcı hesapları oluşturun ve roller tanımlayarak erişim haklarını yönetin.
LDAP ve Active Directory Entegrasyonu: Kurumsal kullanıcı yönetim sistemleri ile entegre edin.
API Anahtarları ve Tokenlar: API erişimlerini güvenli hale getirmek için tokenlar kullanın.
SSL/TLS Konfigürasyonu: Jenkins sunucusunu SSL/TLS ile güvenli hale getirin.
Güncelleme ve Yedekleme: Jenkins ve eklentilerini düzenli olarak güncelleyin ve yedekleme stratejileri oluşturun.

Bu ileri seviye konular, Jenkins'i daha etkili ve güvenli bir şekilde kullanmanıza yardımcı olacaktır. Daha fazla detaya ihtiyaç duyarsanız veya spesifik bir konuda yardım isterseniz, sormaktan çekinmeyin!ChatGPJenkins pipeline'ları iki farklı şekilde tanımlanabilir:

Declarative ve Scripted

Declarative Pipelines: Daha okunabilir ve bakımı kolaydır. Standart yapılandırma ve iş akışı sağlar.
Scripted Pipelines: Daha fazla esneklik sunar. Groovy tabanlıdır ve daha karmaşık iş akışları için uygundur.

Declarative Pipeline Örneği

groovy
pipeline {
    agent any

    environment {
        // Ortak ortam değişkenleri burada tanımlanabilir
        APP_ENV = 'production'
    }

    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
                sh 'scp target/myapp.jar user@server:/path/to/deploy'
            }
        }
    }

    post {
        always {
            echo 'Pipeline tamamlandı'
        }
        success {
            mail to: 'team@example.com',
                 subject: "Build Success",
                 body: "The build was successful."
        }
        failure {
            mail to: 'team@example.com',
                 subject: "Build Failed",
                 body: "The build failed. Please check the Jenkins logs."
        }
    }
}

Scripted Pipeline Örneği

groovy
node {
    stage('Checkout') {
        checkout scm
    }
    stage('Build') {
        try {
            sh 'mvn clean install'
        } catch (Exception e) {
            currentBuild.result = 'FAILURE'
            throw e
        }
    }
    stage('Test') {
        try {
            sh 'mvn test'
        } catch (Exception e) {
            currentBuild.result = 'FAILURE'
            throw e
        }
    }
    stage('Deploy') {
        try {
            if (currentBuild.result == 'SUCCESS') {
                sh 'scp target/myapp.jar user@server:/path/to/deploy'
            }
        } catch (Exception e) {
            currentBuild.result = 'FAILURE'
            throw e
        }
    }
    post {
        always {
            echo 'Pipeline tamamlandı'
        }
        success {
            mail to: 'team@example.com',
                 subject: "Build Success",
                 body: "The build was successful."
        }
        failure {
            mail to: 'team@example.com',
                 subject: "Build Failed",
                 body: "The build failed. Please check the Jenkins logs."
        }
    }
}

Blue Ocean ile Jenkins Pipeline Yönetimi

Blue Ocean, Jenkins pipeline'larını daha görsel ve kullanıcı dostu bir arayüz ile yönetmenizi sağlar.

Kurulum: Blue Ocean eklentisini Jenkins yönetici panelinden yükleyin.
Kullanım: Jenkins ana sayfasında, Blue Ocean sekmesine gidin. Bu arayüzde pipeline'ları görsel olarak oluşturabilir ve yönetebilirsiniz.

Blue Ocean ile Pipeline Oluşturma

Pipeline Kaynağı Seçin: Git, GitHub, Bitbucket gibi bir kaynak seçin.
Depo ve Şube Bilgilerini Girin: Pipeline'ın çekileceği depo ve şubeyi belirleyin.
Pipeline Yapılandırma: Blue Ocean, pipeline yapılandırmasını kolaylaştırır. Adımları görsel olarak ekleyebilir ve düzenleyebilirsiniz.

Jenkins ve Docker Entegrasyonu

Jenkins, Docker ile entegre edilerek yapıların izole ortamlarda çalıştırılmasını sağlar.

Docker ile Jenkins Pipeline Örneği

groovy
pipeline {
    agent {
        docker {
            image 'maven:3.6.3-jdk-8'
            label 'docker'
        }
    }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
    }
}

Bu örnekte, Jenkins pipeline'ı Maven image'ı kullanarak izole bir Docker konteynerinde çalışır. Bu, derleme ve test süreçlerinin daha güvenli ve tutarlı olmasını sağlar.

Jenkins ve Kubernetes Entegrasyonu

Jenkins, büyük ölçekli dağıtık yapılar için Kubernetes ile entegre edilebilir.

Kubernetes Eklentisi: Jenkins yönetici panelinden Kubernetes eklentisini yükleyin.
Kubernetes Cluster Yapılandırma: Jenkins ile Kubernetes cluster'ı entegre edin.
Pipeline Yapılandırma: Pipeline tanımında Kubernetes pod'larını kullanarak iş yüklerini çalıştırın.

Kubernetes Pipeline Örneği

groovy
pipeline {
    agent {
        kubernetes {
            yaml """
            apiVersion: v1
            kind: Pod
            spec:
              containers:
              - name: maven
                image: maven:3.6.3-jdk-8
                command:
                - cat
                tty: true
            """
        }
    }
    stages {
        stage('Build') {
            steps {
                container('maven') {
                    sh 'mvn clean install'
                }
            }
        }
        stage('Test') {
            steps {
                container('maven') {
                    sh 'mvn test'
                }
            }
        }
    }
}

Jenkins İş Akışları ve Bildirimler

Jenkins'te iş akışlarını daha verimli yönetmek için bildirim sistemleri kullanabilirsiniz.

Slack Bildirimleri

Slack Eklentisi: Jenkins yönetici panelinden Slack Notification eklentisini yükleyin.
Slack Webhook URL: Slack'te bir webhook URL oluşturun ve Jenkins'e ekleyin.
Pipeline Bildirimleri: Pipeline tanımına bildirim adımlarını ekleyin.

Slack Bildirimi Örneği

groovy
pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
    }

    post {
        success {
            slackSend (channel: '#build-status', color: 'good', 
message: "Build ${env.JOB_NAME} #${env.BUILD_NUMBER} succeeded")
        }
        failure {
            slackSend (channel: '#build-status', color: 'danger', 
message: "Build ${env.JOB_NAME} #${env.BUILD_NUMBER} failed")
        }
    }
}

Jenkins'te Kullanıcı ve Yetki Yönetimi

Jenkins'te güvenliği sağlamak için kullanıcı ve yetki yönetimini etkili bir şekilde yapmanız gerekir.

Kullanıcı Hesapları: Kullanıcı hesapları oluşturun ve her kullanıcıya özel erişim hakları tanımlayın.
Rol Tabanlı Erişim Kontrolü (RBAC): Rol tabanlı erişim kontrolü ile farklı roller ve bu rollere özel yetkiler belirleyin.
LDAP/Active Directory Entegrasyonu: Kurumsal kullanıcı yönetim sistemleri ile entegre edin.

Jenkins Yedekleme ve Geri Yükleme

Veri kaybını önlemek ve sistem bütünlüğünü korumak için düzenli yedekleme ve geri yükleme stratejileri oluşturun.

Yedekleme: Jenkins yapılandırma dosyalarını, job tanımlarını ve build geçmişini düzenli olarak yedekleyin.
Geri Yükleme: Geri yükleme planları oluşturun ve düzenli olarak test edin.

Jenkins'i daha ileri seviye kullanarak iş akışlarınızı otomatikleştirebilir, güvenliği sağlayabilir ve verimliliği artırabilirsiniz.

Devops

E-Ticaret Platformu Oluşturmak. Bölüm 7 : Jenkins ile uygulamayı CI/CD Pipeline'ına sokarak Dockerize etme, Test Etme ve Kubernetes'e deploy etme

Ali Turgut BOZKURT

Ağustos 17, 2023 Hiç yorum yok

#ecommerce #applicaition #backend #ddd #microservice #kafka #hazelcast #richdomainmodel #spring #java #hibernate
E-Ticaret Platformu Oluşturmak. Bölüm 1 : İhtiyaçları Çıkarmak : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-1.html

E-Ticaret Platformu Oluşturmak. Bölüm 2 : Domain Stroytelling : Katılımcılar, İş Akışları, Kullanıcı Hikayeleri, İlgili Terimler ve Konseptler (Domain), Geliştirme İçin Önceliklendirme, İlgili Dokümantasyonlar : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-2.html

E-Ticaret Platformu Oluşturmak. Bölüm 3 : DDD (Domain-Driven Design): İlgili alt sistemleri ve sınırlı bağlamları tanımları, microservicler, paketler, classlar, class kodları : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-3.html

E-Ticaret Platformu Oluşturmak. Bölüm 4 : Rich Domain Modele Göre Microservicelerdeki Sınıfların Kodlarını oluşturmak : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-4.html

E-Ticaret Platformu Oluşturmak. Bölüm 5 : Apache Kafka ve Hazelcast Cache Entegrasyonu : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-5.html

E-Ticaret Platformu Oluşturmak. Bölüm 6 : Uygulamayı Dockerize etme ve Docker Compose ile localde ayağa kaldırma : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-5_17.html

E-Ticaret Platformu Oluşturmak. Bölüm 7 : Jenkins ile uygulamayı CI/CD Pipeline'ına sokarak Dockerize etme, Test Etme ve Kubernetes'e deploy etme : https://www.turkninja.com/2023/08/e-ticaret-platformu-olusturmak-bolum-7.html

Aşağıda, önceki mesajlarda bahsettiğiniz microservisler için özelleştirilmiş bir Jenkins pipeline ve Kubernetes deployment örneği bulacaksınız.

1. Jenkinsfile

Aşağıdaki Jenkinsfile kodu, her microservis için ayrı ayrı uygulanmalıdır. Microservislerin adlarını uygun şekilde güncellemeniz gerekebilir.

groovy

Copy code

pipeline {

agent any

stages {

stage('Checkout') {

steps {

checkout scm

}

stage('Build & Test') {

steps {

sh './mvnw clean install -DskipTests=false'

}

stage('Docker Build') {

steps {

// microservisin adına göre docker imajını oluştur

sh 'docker build -t user-management:latest ./user-management/'

}

stage('Docker Push') {

steps {

sh 'docker push user-management:latest'

}

stage('Kubernetes Deploy') {

steps {

// microservisin adına göre deploy scriptini çalıştır

sh './deploy-user-management-k8s.sh'

}

2. Kubernetes Deployment (Örnek: User Management Microservice)

Aşağıdaki dosya, kullanıcı yönetimi microservisi için bir Kubernetes deployment örneğidir. Bu YAML dosyasını, microservisin adına göre uygun bir isimle kaydedin, örneğin user-management-deployment.yaml.

yaml

Copy code

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 3

selector:

matchLabels:

app: user-management

template:

metadata:

labels:

app: user-management

spec:

containers:

- name: user-management-container

image: user-management:latest

3. Kubernetes Deploy Scripti (Örnek: User Management)

Aşağıdaki script, kullanıcı yönetimi microservisi için bir Kubernetes deploy script örneğidir. Dosya adı uygun şekilde isimlendirilmelidir, örneğin deploy-user-management-k8s.sh.

bash

Copy code

#!/bin/bash

kubectl apply -f user-management-deployment.yaml

Bu adımları, her bir microservis için uygulayarak, Jenkins CI/CD pipeline'ınızı oluşturabilir ve Kubernetes'e deploy edebilirsiniz. Her microservisin adına, yapılandırmasına ve ihtiyaçlarına uygun şekilde bu kodları özelleştirmeniz gerekebilir.

Türk Ninja

Mega Menu

Trend

Konular

1. Dağıtım Sıklığı (Deployment Frequency)

2. Değişiklik Teslim Süresi (Lead Time for Changes)

3. Başarısızlık Oranı (Change Failure Rate)

4. İyileşme Süresi (Mean Time to Restore)

Senaryo Özet

1. Sharding Nedir?

2. Ortamın Hazırlanması

3. Testlerin Shard'lara Bölünmesi

4. Araçlar ve Çerçeveler

5. Shard'ların Çalıştırılması

6. Sonuçların Toplanması ve Raporlanması

Adım Adım Örnek:

Maven veya Gradle Yapılandırması

Maven

Gradle

JUnit 5 Konfigürasyonu

JUnit Platform Properties

Testlerin Ayrılması

Adım 1: Testleri Gruplara Ayırma

Hızlı Test (Unit Test)

Yavaş Test (Integration Test)

Adım 2: Maven Profilleri Oluşturma

Adım 3: Testleri Çalıştırma

Test Piramidi Kullanımı

1. Birim Testleri:

2. Entegrasyon Testleri:

3. Sistem Testleri:

Test Piramidi'nin Uygulanması

Sonuç

Gürültü (Noise)

Zararlı Sonuçlar (Harmful Effects)

Çözüm Önerileri

Avantajları

Uygulanabilirliği

Uygulama Önerileri

Senaryo:

1. Gecikmiş Entegrasyon:

2. Hataların Geç Tespit Edilmesi:

3. Manuel Test Süreçleri:

4. Dağıtım Süreçlerinde Sorunlar:

5. Düşük Kod Kalitesi:

6. Geri Bildirim Döngüsünün Uzaması:

Çözüm: CI/CD

Jenkins'in Temel Özellikleri

Jenkins Kurulumu

Ön Koşullar

Adımlar

İlk Pipeline (Boru Hattı) Oluşturma

Jenkins ile Daha İleri Seviye Kullanım

Jenkinsfile ile Pipeline Tanımlama

Örnek Jenkinsfile

Jenkins'in En Popüler Eklentileri

Jenkins Master-Slave Mimarisi

Slave (Agent) Ekleme

İleri Seviye Pipeline Özellikleri

Paralel İşlemler

Örnek Paralel İşlem Tanımı

Koşullu Adımlar

Örnek Koşullu Adım Tanımı

Jenkins'te Güvenlik

Declarative Pipeline Örneği

Scripted Pipeline Örneği

Blue Ocean ile Jenkins Pipeline Yönetimi

Blue Ocean ile Pipeline Oluşturma

Jenkins ve Docker Entegrasyonu

Docker ile Jenkins Pipeline Örneği

Jenkins ve Kubernetes Entegrasyonu

Kubernetes Pipeline Örneği

Jenkins İş Akışları ve Bildirimler

Slack Bildirimleri

Slack Bildirimi Örneği

Jenkins'te Kullanıcı ve Yetki Yönetimi

Jenkins Yedekleme ve Geri Yükleme

Rastgele İçerik

Son Yazılar

Rastgele