Sobes.tech
Middle+

Sizcə, bir iş axınında görüntünü qurmaq, test etmək və yerləşdirmək və müxtəlif mühitlərə yerləşdirmək üçün addımlar əlavə etmək düzgün mü?

sobes.tech Süni İntellekt

AI-dan cavab

Bu həmişə optimal olmaya bilər. Belə yanaşma kiçik layihələr və ya yerli test yığmaları üçün əlverişli olsa da, bütün mərhələləri bir iş axışında birləşdirmək çatışmazlıqlara malikdir:

  • Əlverişlilik azaldılması: Müxtəlif mühitlərə (inkişaf, staging, istehsal) yerləşdirmə müxtəlif parametrlər və tez-tez müxtəlif giriş hüquqları tələb edir. Birlikdə etmək bu fərqləri idarə etməyi çətinləşdirir.
  • Mühitə bağlılıq: Əgər bir mühitə yerləşdirmə uğursuz olarsa, bütün yığma uğursuz sayılır, hətta görüntünün yaradılması və testləri uğurla keçibsə belə.
  • Geri alma çətinliyi: Yerləşdirməni geri alma daha az sadə olur, çünki bütün iş axışını geri almaq lazımdır.
  • İcra vaxtının artması: Bütün pipeline daha çox vaxt alır, bu da inkişafçılar üçün geri bildirim müddətini yavaşladır.
  • Daha az miqyaslana bilmə: Layihə böyüdükcə və yerləşdirmə mühitlərinin sayı artsa, bu iş axışı ağır və idarə olunması çətin olur.

Daha çox yayılmış və daha çevik praktika bu mərhələlərin bölünməsidir:

  1. Build & Test Pipeline: Kodun yığılması, test edilməsi, görüntünün yaradılması və artefakt deposuna (məsələn, Docker Registry, Nexus) yerləşdirilməsi üçün məsuliyyət daşıyır. Bu iş axışı hər commit və ya pull request üçün başlayır.
  2. Deployment Pipelines: Hər mühit üçün ayrı iş axışları. Onlar artıq yaradılmış və test edilmiş görüntünü artefakt deposundan götürür və hədəf mühitə yerləşdirir. Bu iş axışları əl ilə, cədvələ uyğun və ya əvvəlki mərhələ uğurla tamamlandıqdan sonra avtomatik başlaya bilər (məsələn, stagingdə uğurlu yerləşdirmə).

Bu aşağıdakıları təmin edir:

  • Kod keyfiyyəti haqqında daha sürətli geri bildirim (build & test).
  • Müxtəlif mühitlərə müstəqil yerləşdirmə.
  • Hər mühit üçün yerləşdirmə parametrlərini daha çevik idarə etmək.
  • Geri alma prosesini sadələşdirmək.

Kiçik pet-layihələr və ya sadə yerləşdirmə prosesi olan monolit tətbiqlər istisna ola bilər, burada bölmənin xərcləri faydalarından çox ola bilər. Ancaq, əksər korporativ mühitlərdə workflow-un bölünməsi ən yaxşı təcrübə hesab olunur.