Sobes.tech
Middle

რა ხდება, როდესაც GitLab კოდი გადმოწერს?

sobes.tech AI

პასუხი AI-სგან

გადმოწერის შემდეგ, GitLab კოდის რეპოზიტორიის სამუშაო დირექტორიაში, იწყება CI/CD პაიპლაინი, რომელიც განსაზღვრულია .gitlab-ci.yml ფაილში.

  1. .gitlab-ci.yml-ის ანალიზი: GitLab Runner (ან GitLab, თუ ინტეგრირებული CI გამოიყენება) კითხულობს კონფიგურაციას .gitlab-ci.yml-დან. ამ ფაილში აღწერილია ეტაპები (stages) და სამუშაოები (jobs) პაიპლაინის.
  2. Runner-ის ინიციალიზაცია: დანიშნულია ხელმისაწვდომი GitLab Runner პაიპლაინის შესასრულებლად. Runner იღებს ინფორმაციას რეპოზიტორიის, კომიტის, ბრენჩის და .gitlab-ci.yml კონფიგურაციის შესახებ.
  3. შესასრულებელი გარემოს შექმნა: Runner-ი ამზადებს გარემოს სამუშაოების შესასრულებლად. ეს შეიძლება იყოს:
    • ვირტუალური მანქანა
    • კონტეინერი (Docker, Kubernetes)
    • გამოყოფილი სერვერი
    • Shell
  4. ეტაპების (stages) შესრულება: პაიპლაინი შესრულდება ეტაპობრივად, განსაზღვრული .gitlab-ci.yml-ში. ერთ ეტაპზე არსებული სამუშაოები შეიძლება შესრულდეს პარალელურად.
  5. სამუშაოების (jobs) შესრულება: თითოეულ ეტაპზე შესრულდება კონფიგურირებული სამუშაოები. სამუშაო მოიცავს:
    • იმიჯის ან აღმასრულებლის (executor) განსაზღვრა, თუ არ არის მითითებული პაიპლაინის ან variables სექციის დონეზე.
    • რეპოზიტორიის კლონირება (უკვე გაკეთებულია GitLab-ით, მაგრამ Runner-ი შეიძლება შეასრულოს git fetch ან git checkout საჭირო მდგომარეობისთვის).
    • ქეშის აღდგენა (თუ არის კონფიგურირებული) აჩქარებისთვის (მაგალითად, დამოკიდებულებების ჩამოტვირთვა).
    • სკრიპტების შესრულება (script): ეს არის სამუშაოს ძირითადი ნაწილი, სადაც შესრულდება კომპილაციის, ტესტირების, ანალიზის ან განთავსების ბრძანებები.
    • არტეფაქტების ატვირთვა (თუ არის კონფიგურირებული): სამუშაოს შედეგები (მაგალითად, კომპილირებული ბინარები, ანგარიშები) ინახება შემდგომი გამოყენებისთვის ან ჩამოტვირთვისთვის.
    • ქეშის შენახვა (თუ არის კონფიგურირებული) მომავალი გაშვების გასამარტივებლად.
  6. სტატუსის ანგარიში: Runner-ი აგზავნის სტატუსს თითოეული სამუშაოს შესრულების შესახებ (წარმატება, შეცდომა, გაუქმება) GitLab-თან. მომხმარებელი ხედავს პროგრესს და შედეგებს პაიპლაინის გვერდზე.
  7. შემდეგი ეტაპისკენ გადასვლა: თუ ყველა სამუშაო მიმდინარე ეტაპზე წარმატებით დასრულდა (ან allow_failure არის დაყენებული), იწყება შემდეგი ეტაპი. თუ სამუშაო დასრულდა შეცდომით და allow_failure არ არის დაყენებული, მთელი პაიპლაინი გაჩერდება.
  8. პაიპლაინის დასრულება: ყველა ეტაპის შესრულების შემდეგ (ან შეცდომის შემთხვევაში) პაიპლაინი დასრულდება. შედეგები და არტეფაქტები ხელმისაწვდომია GitLab-ის ვებ-ინტერფეისით.

მაგალითური სტრუქტურა /.gitlab-ci.yml`:

// განსაზღვრეთ პაიპლაინის ეტაპები
stages:
  - build
  - test
  - deploy

// მშენებლობის სამუშაო ეტაპზე build
build_job:
  stage: build
  image: docker:latest // გამოვიყენოთ Docker-ის იმიჯი
  script:
    - echo "აპლიკაციის მშენებლობა..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Docker იმიჯის მშენებლობა
  artifacts:
    paths:
      - myapp.tar // მშენებლობის არტეფაქტის შენახვა

// ტესტირების სამუშაო ეტაპზე test
test_job:
  stage: test
  image: python:3.9 // გამოვიყენოთ Python-ის იმიჯი
  script:
    - echo "ტესტების გაშვება..."
    - pip install -r requirements.txt
    - pytest // ტესტების შესრულება
  needs: ["build_job"] // დამოკიდებულია build_job-ის წარმატებით დასრულებაზე

// განთავსების სამუშაო ეტაპზე deploy
deploy_job:
  stage: deploy
  image: ubuntu:latest // გამოვიყენოთ Ubuntu-ის იმიჯი
  script:
    - echo "აპლიკაციის განთავსება..."
    - echo "განთავსების სკრიპტი აქაა..." // განთავსების სკრიპტი
  only: // მხოლოდ მესტერის ან ტეგების დროს გაშვება
    - master
    - tags
  needs: ["test_job"] // დამოკიდებულია test_job-ის წარმატებით დასრულებაზე

ამგვარად, კოდის გადმოწერა არის მხოლოდ პირველი ნაბიჯი, რომელსაც მოჰყვება რთული ავტომატიზებული მშენებლობის, ტესტირების და განთავსების პროცესი, რომელიც დაფუძნებულია .gitlab-ci.yml კონფიგურაციაზე.