GitLab CI: ουσία, pipelines και συνεχής ενοποίηση

Τι είναι το GitLab CI;

Το GitLab CI είναι μέρος της ενοποιημένης εφαρμογής DevSecOps GitLab, που περιλαμβάνει συνεχή ενοποίηση, παράδοση και ανάπτυξη. Το σύστημα εμφανίστηκε το 2012 ως ξεχωριστό project, αλλά στη συνέχεια ενσωματώθηκε απευθείας στο GitLab. Η βασική αρχή είναι η διαμόρφωση ως κώδικας (Configuration as Code) μέσω του αρχείου .gitlab-ci.yml στη ρίζα του αποθετηρίου. Το GitLab CI είναι διαθέσιμο τόσο στην έκδοση cloud SaaS όσο και σε self-managed εγκατάσταση.

Για την ανάπτυξη εφαρμογών για κινητά, το GitLab CI προσφέρει αυτοματοποίηση κατασκευής APK και IPA, εκτέλεση ενόργανων δοκιμών, στατική ανάλυση κώδικα, υπογραφή εφαρμογών και δημοσίευση σε καταστήματα. Η πλατφόρμα υποστηρίζει εικόνες Docker για προσαρμοσμένα περιβάλλοντα, επιτρέποντας την προεγκατάσταση Android SDK, NDK, Xcode και άλλων εργαλείων. Το ενσωματωμένο Container Registry απλοποιεί την αποθήκευση και διανομή εικόνων εντός της ομάδας.

Αρχιτεκτονική GitLab CI: Runners, Pipelines και Stages

Η αρχιτεκτονική GitLab CI αποτελείται από τρία βασικά στοιχεία. Το GitLab Runner είναι ο παράγοντας που εκτελεί τα jobs. Οι runners μπορεί να είναι shared (παρέχονται από το GitLab), group (για μια ομάδα projects) και specific (για ένα project). Κάθε runner εγγράφεται με τον καθορισμό του executor: Shell, Docker, Kubernetes ή VirtualBox. Το GitLab Runner υποστηρίζει αυτόματη κλιμάκωση (auto-scaling) για τη διαχείριση φορτίων αιχμής.

Το pipeline είναι μια συλλογή από stages που εκτελούνται διαδοχικά. Μέσα σε ένα stage, τα jobs εκτελούνται παράλληλα. Τυπική δομή για κινητό project: build → test → deploy. Αν ένα job στο stage test ολοκληρωθεί με σφάλμα, το deploy δεν εκκινείται. Μπορεί να ρυθμιστεί χειροκίνητη εκκίνηση (when: manual) για ανάπτυξη. Υποστηρίζονται επίσης ενεργοποιητές multi-project pipelines για σύνθετα σενάρια CI/CD μεταξύ αποθετηρίων.

Executors GitLab Runner

Ο Docker executor είναι ο πιο δημοφιλής για CI/CD εφαρμογών για κινητά. Κάθε job εκτελείται σε ένα καθαρό δοχείο Docker, που εγγυάται απομόνωση και αναπαραγωγιμότητα. Για κατασκευή Android χρησιμοποιείται η εικόνα android-sdk με προεγκατεστημένο SDK, για iOS — macOS runner με Shell executor.

Ρύθμιση .gitlab-ci.yml για κινητά projects

Το αρχείο .gitlab-ci.yml ορίζει το pipeline σε μορφή YAML. Κύριες ενότητες: image (εικόνα Docker), stages (λίστα φάσεων), variables (μεταβλητές περιβάλλοντος), before_script (εντολές πριν από κάθε job) και τα ίδια τα jobs με ενότητες script, artifacts, cache. Το GitLab CI υποστηρίζει include — σύνδεση εξωτερικών αρχείων YAML για επαναχρησιμοποίηση κοινών ρυθμίσεων μεταξύ projects.

Οι μεταβλητές στο GitLab CI μπορούν να οριστούν σε πολλαπλά επίπεδα: καθολικά στο UI, στο αρχείο ρύθμισης, στις ρυθμίσεις ομάδας και project. Η προτεραιότητα μεταβλητών καθορίζεται από την ιεραρχία: οι trigger variables έχουν την υψηλότερη προτεραιότητα, μετά οι CI/CD variables από το UI, μετά από το .gitlab-ci.yml. Οι μεταβλητές μπορούν να προστατευτούν (protected), καθιστώντας τες προσβάσιμες μόνο για προστατευμένα branches και tags.

Βασικές μεταβλητές και εικόνα

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Job κατασκευής με artifacts

Το job generate-apk κατασκευάζει το project Gradle και αποθηκεύει το APK ως artifact. Τα artifacts μεταφέρονται μεταξύ stages — το job deploy μπορεί να χρησιμοποιήσει το APK από το build. Η διάρκεια αποθήκευσης των artifacts ρυθμίζεται μέσω expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: βασικές διαφορές

Κατά την επιλογή μεταξύ GitLab CI και GitHub Actions για κινητό project, είναι σημαντικό να ληφθεί υπόψη η υποδομή της ομάδας. Το GitLab CI παρέχει ενσωματωμένο Container Registry που μπορεί να χρησιμοποιηθεί για αποθήκευση εικόνων Docker με Android SDK. Το GitHub Actions βασίζεται στο GitHub Packages ή σε εξωτερικά μητρώα. Το GitLab έχει επίσης ενσωματωμένο SAST (Στατική Δοκιμή Ασφάλειας Εφαρμογών) για ανάλυση κώδικα για ευπάθειες.

Το GitLab CI προσφέρει πιο ευέλικτο μοντέλο runners — υποστηρίζει Kubernetes executor, αυτόματη κλιμάκωση και προσαρμοσμένες εικόνες. Το GitHub Actions κερδίζει στην ενσωμάτωση με το οικοσύστημα GitHub και την αγορά actions. Το GitLab CI απαιτεί χειροκίνητη ρύθμιση για πολλές εργασίες που στο GitHub Actions λύνονται με έτοιμο action.

Από την άποψη CI/CD για κινητά projects: το GitLab CI είναι πιο κατάλληλο για εταιρείες που ήδη χρησιμοποιούν GitLab Self-Managed και απαιτούν self-hosted runners με Docker/Kubernetes. Το GitHub Actions είναι πιο βολικό για μικρές ομάδες στο cloud GitHub που εκτιμούν τα έτοιμα actions και την απλή ρύθμιση.

Σύγκριση δυνατοτήτων

Παράδειγμα pipeline για project Android

Το πλήρες pipeline για Android περιλαμβάνει: lint, δοκιμές μονάδας, κατασκευή και ανάπτυξη στο Firebase App Distribution. Το pipeline χρησιμοποιεί μια εικόνα Docker με Android SDK, προσωρινή αποθήκευση Gradle και παράλληλη εκτέλεση lint και δοκιμών σε ένα stage. Αυτή η προσέγγιση μειώνει τον συνολικό χρόνο του pipeline, καθώς οι εργασίες lint και test δεν εξαρτώνται η μία από την άλλη.

Για projects iOS, η δομή του pipeline διαφέρει λόγω της ανάγκης για macOS runner και υπογραφής κώδικα. Το τυπικό pipeline iOS περιλαμβάνει: εγκατάσταση CocoaPods ή SPM, εκτέλεση δοκιμών σε προσομοιωτή, αρχειοθέτηση του project Xcode, εξαγωγή IPA και μεταφόρτωση στο TestFlight. Το GitLab CI για iOS χρησιμοποιεί macOS runners — είτε GitLab SaaS macOS runners με χρονικούς περιορισμούς, είτε self-hosted runner σε Mac mini ή MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

Βελτιστοποίηση χρόνου κατασκευής στο GitLab CI

Η βελτιστοποίηση των pipeline κατασκευής για κινητά στο GitLab CI απαιτεί προσοχή στη λεπτομέρεια. Η σωστή ρύθμιση των cache και artifacts επιτρέπει τη μείωση του χρόνου κατασκευής πολλές φορές. Για ανάλυση απόδοσης, το GitLab παρέχει CI/CD Analytics — έναν πίνακα ελέγχου με μετρήσεις διάρκειας pipeline, φόρτου runners και σημείων συμφόρησης. Αναλύετε αυτές τις μετρήσεις τακτικά για να βρείτε ευκαιρίες βελτιστοποίησης. Η ρύθμιση resource_group μπλοκάρει την παράλληλη εκτέλεση ενός pipeline — χρήσιμο για την αποφυγή συγκρούσεων κατά την ανάπτυξη.

Η στρατηγική branch για CI είναι επίσης σημαντική. Συνιστάται η εκτέλεση πλήρους pipeline μόνο για τα branches main και release, και για τα feature branches — μόνο lint και δοκιμές μονάδας. Αυτό εξοικονομεί λεπτά runners και επιταχύνει την ανατροφοδότηση στους προγραμματιστές. Το GitLab CI υποστηρίζει workflow:rules — υπό όρους κανόνες για συμπερίληψη ή αποκλεισμό jobs ανάλογα με το branch, τροποποιημένα αρχεία ή μεταβλητές περιβάλλοντος.

Η προσωρινή αποθήκευση εξαρτήσεων είναι ο κύριος τρόπος επιτάχυνσης. Το GitLab CI αποθηκεύει προσωρινά .gradle, Pods και node_modules μεταξύ εκτελέσεων. Το κλειδί cache περιλαμβάνει το $CI_COMMIT_REF_SLUG ή το hash του αρχείου lock. Ο χρόνος κατασκευής ενός project Android μειώνεται από 10–15 σε 2–4 λεπτά με σωστή προσωρινή αποθήκευση. Η προσωρινή αποθήκευση μπορεί να είναι κατανεμημένη — το GitLab υποστηρίζει cache:key με επαναφορά σε προηγούμενα κλειδιά.

Μια εικόνα Docker με προεγκατεστημένα εργαλεία εξοικονομεί χρόνο εγκατάστασης. Συνιστάται η δημιουργία προσαρμοσμένης εικόνας με Android SDK, NDK και το απαιτούμενο επίπεδο API. Η παράλληλη εκτέλεση jobs (lint, test, assemble) σε διαφορετικά stages μειώνει τον συνολικό χρόνο pipeline. Οι πολιτικές έλξης (pull policies) για εικόνες (if-not-present) επιταχύνουν την έναρξη jobs. Μπορεί επίσης να χρησιμοποιηθεί dependency proxy για προσωρινή αποθήκευση εικόνων σε επίπεδο παρουσίας GitLab.

Μια άλλη σημαντική πτυχή βελτιστοποίησης είναι η χρήση artifacts μεταξύ φάσεων. Τα βαριά αρχεία APK και IPA είναι καλύτερο να μεταφέρονται μέσω dependency παρά να ξανακατασκευάζονται σε κάθε job. Για μεγάλα projects με δεκάδες modules, συνιστάται η ενεργοποίηση του Gradle Build Cache σε επίπεδο pipeline και η ρύθμιση απομακρυσμένης προσωρινής αποθήκευσης (remote cache) σε κοινό χώρο αποθήκευσης. Το timeout για κάθε job πρέπει να ορίζεται βάσει του αναμενόμενου χρόνου κατασκευής — αυτό αποτρέπει τις κολλημένες διαδικασίες.

Παράδειγμα με προσωρινή αποθήκευση και pull policy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present