DEV Community: Enes Gerem

Software Testing

Enes Gerem — Mon, 28 Jun 2021 07:30:32 +0000

What software testing is and is NOT

Testing is to execute a program with the intent of finding as many defects as possible and/or gaining sufficient confidence in the software system under test
Testing is not cut-and-fit improvement of a user interface or requirements elicitation by prototyping.
Testing is not the verification of an analysis or design model by syntax checkers or simulation.
Testing is not the scrutiny of documentation or code by humans in inspections, reviews, or walkthroughs.
Testing is not static analysis of code using a language translator or code checker.
Testing is not the use of dynamic analyzers to identify memory leaks or similar problems.
Testing is not debugging, although successful testing should lead to debugging.

Some Definitions

Error

The very root cause. Errors are committed by people.

Fault

A fault is the result of a human error in the software documentation, code, etc.

Failure

A failure occurs when a fault executes.

Incident

Consequences of failures; failure occurence may or may not be apparent to the user.

Defect

Any of the above, usually a fault, aka bug.

The fundamental chain of SW dependability threats:

Error----propagation---->Fault----causation---->Failure----results in---->Incident

What is a Test Case and Test Suite (Test Set)?

A test case is set of inputs and the expected outputs for a unit/module/system under test.
A test suite (test set) is set of test cases (at least one)
Without the expected outputs, a test case is not complete.

Types of Test Activities

Exploratory (Human Based)

Design test values based on domain knowledge of the program and human knowledge of testing.

Criteria-based

Design test values to satisfy coverage criteria, covering all lines of codes.

Test Automation

Embed test values into executable scripts.

Test Execution

Run tests the on the software and record the results.

Test Evaluation

Evaluate results of testing, report to developers.

Types of Testing

Functional testing is testing the functional requirements.
Non-functional testing is testing the non-functional requirements. Such as,
- Performance, Load, Endurance, Localization, Recovery, Security, Stress etc.

Exhaustive Testing

Testing a software system using all the possible inputs, not possible mostly.

For example exhaustive testing of a compiler program would be compiling all possible codes, which is not possible.

When can we say testing is enough?

A test-adequacy criterion leads to test obligations. Test coverage is the percentage of obligations that are met.

Functional tests black-box, Structural tests are white-box
- Specification -> Black-Box Testing
- Implementation -> White (glass)-Box Testing
Missing functionallities cannot be revealed by white-box techniques. -> at Spesification
Unexpected functionallities cannot be revealed by black-box techniques. -> at Implementation

Testing throughout the SDLC - in Waterfall

SDLC: Software Development Life Cycle
Much of the life-cycle development artifacts provides a rich source of test data.
Identifying test requirements and test cases early helps shorten the development time.
They may help reveal faults.
It may also help identify early low testable specifications or design.

Analysis --- Design --- Implementation --- Testing:

Preparation for Test --- Preparation for Test --- Unit Testing --- Acceptance system Testing

Black-Box Testing

Based on the definition of a program's specification, as opposed to its structure (code, interface)
The notion of complete coverage can also be applied to function (Black-box) testing.
Rigorous specifications have another benefit, they help black-box testing, e.g., categorize inputs, derive expected outputs.
In other words, they help test case generation and test oracles.

Different Techniques

Equivalence Class Testing

We would like to have a sense of complete testing and we would hope to avoid test redundancy.

Equivalence classes partitions of the input set in which input data have the same effect on the program. (e.g. the result in the same output).
Entire input set is covered in testing, completeness.
Disjoint classes to avoid redundancy.
Test cases one element of each equivalence class.
Guessing the likely system behaviour might be needed.

Boundary-Value Analysis

In equivalence class testing, we partitioned input domains into equivalence classes, on the assumption that the behavior
of the program is similar for all input values of a equivalence class.

Above assumption may not ve true in all cases as some typical programming errors happen to be at the boundary between
different equivalence classes.

This is what boundary value testing focuses on, simpler but complementary to equivalence class testing.

Catergory-Partition Testing

The system is divided into individual functions that can be independently tested.
The method identifies the parameters of each function and, for each parameter, identifies distinct categories.
Besides parameters, environment characteristics, under which the function operates (characteristics of the system state), can also be considered.
Categories are major properties or characteristics for each parameter
The categories are further subdivided into choices in the same way as equivalence partitioning is applied (possible “values”).
A broader idea compared to Equivalence-Class Partitioning.
In essence: Category-partition testing integrates equivalence class testing, boundary analysis, and adds a few refinements.

Decision Tables

To help express test requirements in a directly usable form.
Easy to understand and support the systematic derivation of test cases
To support automated or manual generation of test cases.
A particular response or response subset is to be selected for testing by evaluating many related conditions
Ideal for describing situations in which a number of combinations of actions are taken under varying sets of conditions, e.g., control systems

Cause-Effect Graphs

Graphical technique that helps derive decision tables
Aims at supporting interaction with domain experts and the reverse engineering of specifications, for the purpose of testing.
Identify causes (conditions on inputs, stimuli) and effects (outputs, changes in system state).
Causes have to be stated in such a way to be either true or false.
Can be used to explicitly specify constraints on causes and effects.
They can help select more “significant” subset of input/output combinations and build smaller decision tables.

YAML

Enes Gerem — Mon, 28 Jun 2021 07:22:18 +0000

YAML yazılım dünyasında artık her yerde karşımıza çıkan bir dosya formatı ve configürasyon dosyası alternatifi haline geldi. Fakat nedir bu YAML?

YAML (YAML Ain't Markup Language) dil bağımsız bir veri değişim formatıdır. Herhangi bir programlama dili ile oluşturulan nesneler, YAML formatında kolaylıkla temsil edilebilmektedir. YAML geniş veri tipi desteği sayesinde tüm diller arasında ortak olarak kullanılabilir olmakla birlikte, ayrıca insan gözüyle bakıldığında kolay okunabilir bir yapısı mevcuttur.

YAML, konfigürasyon dosyaları için ve verilerin depolandığı veya iletildiği uygulamalarda yaygın olarak kullanılır. XML(Extensible Markup Language)'in kullanıldığı uygulamaların çoğunu hedefler ancak SGML(Standard Generalized Markup Language)'den kasıtlı olarak farklı olan minimal bir sözdizimine sahiptir.

YAML Syntaxı

YAML Nested yapısını belirtmek için Python tarzı girintiyi, listeler için köşeli parantezleri [...] ve mapler için süslü
parantezleri {...} barındıran daha kompakt bir biçim kullanır.

Bazı basit kurallar;

Yapıyı belirtmek için boşluk girintisi kullanılır; ancak, bu girintinin parçası olarak sekme karakterlerine izin verilmez.
Yorumlar "#" ile başlar, bir satırda herhangi bir yerden başlayabilir ve satırın sonuna kadar devam edebilir.

# Bu bir yorum satırıdır.

Liste elemanları, her satırda bir eleman olacak şekilde "-" ile veya köşeli parantezlerin içine elemanları virgülle ayırarak gösterilir.

# Listelerin tanımlanma şekilleri
- A
- B
- C

  [ A,B,C ]

Dictionary yapısı "key:value" formunda her satırda bir eleman olacak şekilde listelenebilir.

# Dictionary
enes:
  name: Enes Gerem
  age: 23

Dictionary listesi aşağıdaki gibi belirtilebilir.

# Dictionary listesi
- enes:
  name: Enes Gerem
  age: 23

- emre:
  name: Emre Basar
  age: 22

Alternatif olarak dictionary yapısı süslü parantezlerle de belirtilebilir.
"|" ve ">" kullanarak, tanımlar birden çok satırda belirtilebilir. Satır başı karakterini de almak istediğimiz de "|",
tek bir satır yazacaksak ve sadece okunabilirliği arttırmak istiyorsak ">" kullanabiliriz.

include_newlines: |
  bu String tam olarak
  bu sekilde
  gozukecektir

fold_newlines: >
  bu değer aslinda
  sadece bir satiri
  ifade eder

İki nokta'dan ":" sonra bir boşluk varsa bu bir dictionaryi temsil eder. Eğer iki noktayı value kısmında kullanmak istiyorsak boşluk olmadan, escape karakteriyle ya da tırnak içinde kullanmamız gerekir.
Değişkenler "{var}" formatında belirtilebilir.

foo: "{variable}"

Aşağıda YAML formatında hazırlanmış YAML formatı için derlenen referans dosyası incelenebilir.
Kaynak: yaml.org

%YAML 1.1   # Reference card
---
Collection indicators:
  '? ': Key indicator.
  ': ': Value indicator.
  '- ': Nested series entry indicator.
  ', ': Separate in-line branch entries.
  '[]': Surround in-line series branch.
  '{}': Surround in-line keyed branch.
Scalar indicators:
  '''': Surround in-line unescaped scalar ('' escaped ').
  '"': Surround in-line escaped scalar (see escape codes below).
  '|': Block scalar indicator.
  '>': Folded scalar indicator.
  '-': Strip chomp modifier ('|-' or '>-').
  '+': Keep chomp modifier ('|+' or '>+').
  1-9: Explicit indentation modifier ('|1' or '>2').
  # Modifiers can be combined ('|2-', '>+1').
Alias indicators:
  '&': Anchor property.
  '*': Alias indicator.
Tag property: # Usually unspecified.
  none: Unspecified tag (automatically resolved by application).
  '!': Non-specific tag (by default, "!!map"/"!!seq"/"!!str").
  '!foo': Primary (by convention, means a local "!foo" tag).
  '!!foo': Secondary (by convention, means "tag:yaml.org,2002:foo").
  '!h!foo': Requires "%TAG !h! <prefix>" (and then means "<prefix>foo").
  '!<foo>': Verbatim tag (always means "foo").
Document indicators:
  '%': Directive indicator.
  '---': Document header.
  '...': Document terminator.
Misc indicators:
  ' #': Throwaway comment indicator.
  '`@': Both reserved for future use.
Special keys:
  '=': Default "value" mapping key.
  '<<': Merge keys from another mapping.
Core types: # Default automatic tags.
  '!!map': { Hash table, dictionary, mapping }
  '!!seq': { List, array, tuple, vector, sequence }
  '!!str': Unicode string
More types:
  '!!set': { cherries, plums, apples }
  '!!omap': [ one: 1, two: 2 ]
Language Independent Scalar types:
  { ~, null }: Null (no value).
    [ 1234, 0x4D2, 02333 ]: [ Decimal int, Hexadecimal int, Octal int ]
    [ 1_230.15, 12.3015e+02 ]: [ Fixed float, Exponential float ]
    [ .inf, -.Inf, .NAN ]: [ Infinity (float), Negative, Not a number ]
    { Y, true, Yes, ON }: Boolean true
    { n, FALSE, No, off }: Boolean false
    ? !!binary >
      R0lG...BADS=
      : >-
      Base 64 binary value.
Escape codes:
  Numeric: { "\x12": 8-bit, "\u1234": 16-bit, "\U00102030": 32-bit }
  Protective: { "\\": '\', "\"": '"', "\ ": ' ', "\<TAB>": TAB }
  C: { "\0": NUL, "\a": BEL, "\b": BS, "\f": FF, "\n": LF, "\r": CR,
       "\t": TAB, "\v": VTAB }
  Additional: { "\e": ESC, "\_": NBSP, "\N": NEL, "\L": LS, "\P": PS }
...

YAML artık birçok framework'ün tercih ettiği configuration formatı haline geldi. En popüler front-end Web framework'ü
React'te ve mobil framework'ü Flutter'da bu yapıyı görmek mümkün.

Örnek olması açısından aşağıda Flutter projelerimden birinin "pubspec.yaml" configuration dosyası incelenebilir.

name: receipt_scanner
description: Receipt scanner app

# The following defines the version and build number for your application.
# A version number is three numbers separated by dots, like 1.2.43
# followed by an optional build number separated by a +.
# Both the version and the builder number may be overridden in flutter
# build by specifying --build-name and --build-number, respectively.
# In Android, build-name is used as versionName while build-number used as versionCode.
# Read more about Android versioning at https://developer.android.com/studio/publish/versioning
# In iOS, build-name is used as CFBundleShortVersionString while build-number used as CFBundleVersion.
# Read more about iOS versioning at
# https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
version: 1.0.0+1

environment:
  sdk: ">=2.1.0 <3.0.0"

dependencies:
  flutter:
    sdk: flutter

  cupertino_icons: ^0.1.2
  firebase_ml_vision:
  image_picker:
  image_cropper:
  path_provider: ^1.6.11
  mailer: ^3.0.4
  excel: ^1.1.5
  camera_camera: ^1.0.34+1
  firebase_auth: ^0.16.1
  cloud_firestore: ^0.13.7
  provider: ^3.1.0
  flutter_spinkit: ^4.1.2+1
  http: ^0.12.0+3
  sqflite: ^1.3.1
  google_sign_in: ^4.5.1
  camera: ^0.5.8+5
  path: ^1.6.4
  auto_size_text: ^2.1.0
  flushbar: ^1.5.0
  rxdart: ^0.24.1


dev_dependencies:
  flutter_test:
    sdk: flutter

  flutter_launcher_icons: "^0.7.3"


flutter_icons:
  android: true
  ios: true
  image_path: "assets/icon/voucher_logo.png"


# The following section is specific to Flutter.
flutter:

  # The following line ensures that the Material Icons font is
  # included with your application, so that you can use the icons in
  # the material Icons class.
  uses-material-design: true

  assets:
  - assets/image/google.png
  - assets/image/bg.png
  - assets/files/example.xlsx
  - assets/files/temp.xlsx
  - assets/background/top.png
  - assets/background/right.png
  - assets/background/bttm.png
  - assets/icon/google.png
  - assets/icon/facebook.png
  - assets/icon/apple.png
  - assets/icon/twitter.png
  - assets/icon/receipt_logo.png
  - assets/icon/splash_screen.png
  - assets/icon/profile.png
  - assets/icon/data.png
  - assets/icon/home.png
  - assets/icon/homeon.png
  - assets/icon/dataon.png
  - assets/icon/profileon.png
  - assets/icon/user.png
  - assets/icon/lock.png

  fonts:
    - family: Poppins
      fonts:
        - asset: fonts/Poppins/Poppins-Black.ttf
          weight: 900
        - asset: fonts/Poppins/Poppins-Bold.ttf
          weight: 700
        - asset: fonts/Poppins/Poppins-ExtraBold.ttf
          weight: 800
        - asset: fonts/Poppins/Poppins-Light.ttf
          weight: 400
        - asset: fonts/Poppins/Poppins-Medium.ttf
          weight: 600
        - asset: fonts/Poppins/Poppins-Regular.ttf
          weight: 500
        - asset: fonts/Poppins/Poppins-SemiBold.ttf
          weight: 700

    - family: Spartan
      fonts:
          - asset: fonts/Spartan-VariableFont_wght.ttf

Clean Code

Enes Gerem — Mon, 28 Jun 2021 07:11:33 +0000

Projelerin geliştirilme aşamasında sonrası için hayat kurtarması muhtemel olan bazı dizayn prensipleri.

Projeleri geliştirirken kullanılan teknolojilerin dosyaları aynı uzantı ismiyle açılan paketlerde tutulması gerekir.
- Örneğin /js yolu JavaScript dosyalarını içermeli, /css yolu CSS dosyalarını içermeli gibi.

Proje içerisinde değişken, fonksiyon, sınıf gibi isimlendirmeler isimlendirmeler içerik hakkında olması gerektiği kadar bilgi vermelidir.
- Sınıf isimlendirmeleri o sınıftan oluşacak objeler hakkında, method isimlendirmeleri o methodun yaptığı iş hakkında, ne çok kısaltılmış ne de çok detaya girilmiş şekilde, görüldüğünde ne işe yaradığını belirtecek kadar bilgi barındırmalı.
- Fonksiyon isimlendirmeleri yapacağı işlev hakkında fiil içermeli, sınıf isimlendirmeleri içermemelidir.

Koşul içerikleri çok komplike olmamalı, okuyanlar tarafından rahat anlaşılabilmeli.
- İç içe koşul kontrollerinden kaçınılmalı.

Tekrar eden kodlardan kurtulunmalı. Örneğin eğer bir kod parçacığı ikiden fazla tekrar ediyorsa fonksiyon haline getirilmeli.
- Fonksiyonlar karmaşık olmamalı, tek işlev için tek fonksiyon kullanılmalı.
- Fonksiyonların parametre sayısı mümkün olan en az sayı olmalıdır.
- Dilin sağladığı lambda fonksiyonları kullanmak bazen kodu uzun uzun yazmaktan daha anlaşılırdır.

Kodun içerisinde çıkabilecek hataları kontrol ederken yapılan handling operasyonlarından loglar düzgün ve anlaşılır şekilde döndürülmeli ki kodun hatası yutulmadan ve büyük problemlere sebep olmadan hata çözülsün.

Bir sınıf kendi objesinin özellikleri ve fonksiyonelliği haricinde işlev barındırmamalı ve olabildiğince minimal tutulmalı.
- Sınıflar sadece bir amaca hizmet etmelidir.

İyi yerleştirilmiş yorum satırlarının kodu okuyanlara faydalı olmasının yanında, kodun olabildiğince yorum satırı ihtiyacı ortadan kaldırılmalı. Kodun düzeni ne kadar iyi olursa o kod o kadar az yorum satırı ihtiyacı duyar.

Değişkenlerin kullanılacağı yerden çok uzakta tanımlamak kodun okunurluğunu ciddi oranda düşürür.
- Kodu okuyan insanlar sanki bir makale okuyormuş gibi okuyabilmelidir.
- Kodun en üst kısmında algoritme ve konsept hakkında kısa bir giriş paragrafı yapılmalı.

Encapsulation mümkün olan her yerde uygulanmalı.
- Modüllerin birbirilerine müdahale etmeleri kısıtlanmalı.
- Böylelikle gevşekçe bağlı modüller üretilmiş ve kodun anlaşılabilirliği ve geliştirilebilirliği arttırılmış olur.

Kod üzerinde yapılan testler hızlı, birbirinden bağımsız, tekrar kullanılabilir, kendini değerlendirebilen ve zamanında yazılmış olma özelliklerine sahip olmalıdır.

Bir sistemi basit ve kolayca geliştirilebilir kılan özellikler şunlardır;
- Tüm testleri başarıyla geçer
- Kod tekrarı yoktur
- Geliştiricinin niyeti kolayca anlaşılır
- Sınıf ve metot sayısı minimaldir

Sistemde olabildiğince soyutlama kuralları uygulanmalıdır.
- Fonksiyonel ortaklığı olmayan sınıflar birbirleriyle iletişim halinde olmamalıdır.
- Geliştirici doğru design patternlar kullanarak modül bağımlılığını ortadan kaldırmalıdır.

Kodun yazılış formatına her zaman dikkat edilmelidir ki okunabilirliği en çok etkileyen faktörlerden biridir.
- Çalışma ortamının sağladığı formatlama fonksiyonlar bu konuda oldukça faydalıdır.

Genel dizayn kuralları,
- Kodun üst tabakalarında düzenlenebilir veriler tutulmalı
- Dilin sağladığı şekilde kodun bağımlılığı azaltılmalı. Örneğin interface'ler kullanılarak ortak türler tanımlanmalı. Mantıksal bağımlılıklar doğru çalışan class'ları dahi zamanla zincirleme etkisi sonucu bozabilir.
- Mümkün olan her yerde dependecy injection yapılmalı, tekrar tanımlamadan kaçınılmalı.
- Dilin conventional standartları okuyanların daha rahat anlamasına yardımcı olur. Örneğin Java'da fonksiyon isimlendirmelerinin birden fazla kelime içermesi durumunda Camel Case kullanılması, Python'da ise büyük harfe yer verilmeyip birden fazla kelime içermesi durumunda alt tire karakteriyle ayrılması gibi.

CI/CD

Enes Gerem — Mon, 28 Jun 2021 07:04:56 +0000

Continuous Integration

Basitçe, tüm geliştiriciler tarafından yapılan işleri günde birkaç kez paylaşılan bir ana hatta birleştirme uygulaması.

Kodu bir Git reposunda saklanan bir uygulama göz önüne alındığında, geliştiriciler, bir uygulama için kod değişikliklerini gün içerisinde birden çok kez pushlar.
Repoya yapılan her pushlama için, uygulamayı otomatik olarak oluşturmak ve test etmek için bir dizi komut dosyası oluşturulabilir. Bunlar
komut dosyaları, uygulamada hatalara neden olma olasılığını azaltmaya yardımcı olur.

Bir dalda ana hatta birleşmeden geliştirme ne kadar uzun sürerse, çoklu
geliştirici dalı sonunda tekrar birleştirildiğinde entegrasyon çakışmaları ve başarısızlıklar oluşması riski o kadar artar. Geliştiriciler kod gönderdiğinde
kopyalarını aldıkları andan itibaren repodaki değişiklikleri yansıtmak için önce kodlarını güncellemeleri gerekir.
Repo ne kadar çok değişiklik içeriyorsa, geliştiricilerin kendi değişikliklerini göndermeden önce o kadar çok iş yapması gerekir.

Bir uygulamaya gönderilen her değişiklik, otomatik ve sürekli olarak oluşturulur ve test edilir. Bahsedilen testler değişikliklerin tüm testlerden geçtiğini, kod içerisindeki yönergelerin ve kod uyumluluk standartlarının geçerliliğini kontrol eder.

Continuous Delivery & Deployment

Sürekli Teslimat, her seferinde yalnızca uygulamanın oluşturulduğu ve test edildiği Sürekli Entegrasyonun ötesinde bir adımdır.
kod değişikliği kod tabanına aktarılır, ancak uygulama da sürekli olarak dağıtılır. Sürekli Teslimat
kodu otomatik olarak kontrol eder, ancak değişikliğin dağıtımı manuel olarak gerçekleşir ve stratejik olarak tetiklemek için insan müdahalesi gerektirir.

Sürekli Dağıtım, Sürekli Teslimata benzer bir başka adımdır. Aradaki fark,
uygulama manuel olarak dağıtımının yerine, otomatik olarak dağıtılacak şekilde ayarlanmıştır, bu nedenle insan müdahalesi gerekmez.

Deployment pipeline, yazılım kalitesini iyileştirmek, kararlılığı arttırıp kodun maliyetini düşürmek adına yapılandırma yönetimini, sürekli entegrasyonu ve dağıtım otomasyonunu bir arada birbirine bağlar.

Deploymentlarda dikkat edilmesi gerekenler;

Paketleri yalnızca bir kez oluşturmak. Dağıttığımız projenin deployment pipeline boyunca baştan beri test ettiğimiz projeyle aynı olduğundan emin olmak istiyoruz, böylece bir dağıtım başarısız olursa, paketleri hatanın kaynağı olarak ortadan kaldırabiliriz.
Geliştirme dahil her ortama aynı şekilde dağıtmak. Bu şekilde, dağıtım sürecini birçok kez test ediyoruz. Herhangi bir sorun kaynağının ortadan kaldırılabilmesi için üretime geçme aşamasından önce gerçekleştirilebiliyor.
Dağıtımlarınızı duman testi ile test etmek Uygulamanın tüm bağımlılıklarını doğrulayan bir komut dosyasına sahip olun. uygulamanın yapılandırıldığı konum, uygulamanın çalıştığından ve uygulamanın dağıtım sürecenin bir parçası olarak kullanılabilir olduğundan emin olun.
Ortamları benzer tutmak Donanım yapılandırmasında farklılık gösterseler de aynı işletim sistemi ve ara yazılım paketlerinin sürümü ve aynı şekilde yapılandırılmalıdır. Günümüzde modern sanallaştırma ve kapsayıcı teknolojisi ile bunu başarmak çok daha kolay hale geldi.

GitLab'da CI/CD

GitLab, kendisine ait olan Sürekli Entegrasyon ve Sürekli Dağıtım sistemiyle oluşturulmuştur. Bir GitLab projesinde, projenin yapılandırılması için gitlab-ci.yml adlı bir configuration dosyası reponun içine yerleştirilir. Dosya, projede gerçekleşen her bir push komutuyla uygulamanın inşasının ve testinin tapılacağı GitLab Runner tarafından yürütülür.

GitLab Runner projenin işlerini çalıştırmak ve sonuçları GitLab'a geri göndermek için kullanılan açık kaynaklı bir projedir. Bu servis GitLab'a dahil olup CI ve CD'den ardışık düzen komut dosyasını yürütmek için onunla birlikte kullanılır.

GitLab'da CI/CD Örneği

Bu örnek proje bir küme yönetim sistemi olan Google Cloud Container Engine'e deploy edilecektir.

Gereksinimler; Dockerfile, Kubernetes deployment.

Spring Boot uygulamasını Docker Container olarak paketleme

FROM adoptopenjdk/openjdk11:alpine-jre
VOLUME /tmp
ADD /target/cdexample-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

Kubernetes deployment'ı tanımlama

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cdexample
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: cdexample
    spec:
      containers:
        - name: cdexample
          image: registry.gitlab.com/enesgerem/cdexample
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
      imagePullSecrets:
        - name: registry.gitlab.com

Bir GitLab CI Pipeline oluşturma

Yukarıdaki dosyaları commitleyip pushladıktan sonra GitLab CI Pipeline'ı tanımlamaya hazırız.

image: docker:latest
services:
  - docker:dind

variables:
  DOCKER_DRIVER: overlay2
  SPRING_PROFILES_ACTIVE: gitlab-ci

stages:
  - build
  - package
  - deploy

maven-build:
  image: maven:3.8.1-jdk-11
  stage: build
  script: "mvn package -B"
  artifacts:
    paths:
      - target/*.jar

docker-build:
  stage: package
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker build -t registry.gitlab.com/enesgerem/cdexample .
    - docker push registry.gitlab.com/enesgerem/cdexample

k8s-deploy:
  image: google/cloud-sdk
  stage: deploy
  script:
    - echo "$GOOGLE_KEY" > key.json
    - gcloud auth activate-service-account --key-file key.json
    - gcloud config set compute/zone europe-west1-c
    - gcloud config set project cdexample
    - gcloud config set container/use_client_certificate True
    - gcloud container clusters get-credentials cdexample
    - kubectl delete secret registry.gitlab.com
    - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=enesgerem --docker-password=$REGISTRY_PASSWD --docker-email=enesgerem@gmail.com
    - kubectl apply -f deployment.yml

image objesi kullanmak istediğimiz Docker image'ın ismini tanımlar.
services objesi projeye linklenmiş kullanmak istediğimiz ek Docker image'larını tanımlar.
variables objesi oluşturduğumuz environment içindeki değişkenleri tanımlar.
- DOCKER_DRIVER hangi depolama sürücülerini kullandığımızı Docker Engine'a bildirir.
- SPRING_PROFILES_ACTIVE uygulamamızın bölümlerini ayıran ve yalnızca belirli ortamlarda kullanılabilir hale getirmenin bir tolunu sağlayan Spring Profiles'ı etkinleştirir.
stages objesi build'ımızın yaşam döngüsünü tanımlar.
maven-build, docker-build ve k8s-deploy iş tanımlamalarıdır.
- $GOOGLE_KEY Google Cloud serviste kullandığımız hesap anahtarımızdır, API Manager Section'daki Google Cloud Platform'dan edinilir.
- kubectl create secret docker-registery ... kodu deployment.yml içinde tanımladığımız imagePullSecret objesini yaratır.

Son olarak, her şeyin yolunda olduğunu kontrol etmek adına küme aşağıdaki gibi kontrol edilebilir.

$ kubectl get deployments
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE    AGE
cdexample   2         2         2            2            2m

$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
cdexample-3641958612-3e5xy   1/1       Running   0          2m
cdexample-5542343546-fr4gh   1/1       Running   0          2m