در بسیاری از سازمان ها ، تیم های نرم افزاری خطوط لوله CI/CD خود را برای مقابله با وظایف مکرر مانند بررسی کد ، آزمایش ، اسکن ، ساخت و استقرار توسعه می دهند. این روش فردی غالباً منجر به تلاش اضافی غیر ضروری برای پیکربندی و نگهداری می شود ، که هزینه ای برای سرمایه گذاری بهتر در توسعه ویژگی های جدید دارد. اگرچه وظایف و گردش کار بین تیم ها مشابه است ، اما هر تیم به جای بهره مندی از راه حل های موجود ، چرخ را دوباره زنده می کند. این عمل می تواند چرخه آزادی را گسترش داده و باعث اختلال در کارآیی تیم ها شود.

برای برآورده کردن این چالش ها ، ایجاد استانداردهای گسترده شرکت برای خطوط لوله CI/CD منطقی است. این می تواند با ارائه ماژول های استاندارد قابل استفاده مجدد مانند الگوهای شغلی و اجزای GitLab انجام شود ، که به صورت مرکزی فهرست بندی ، مستند شده و در بین تیم ها شناخته می شوند. چنین ماژول هایی باید عمومی و انعطاف پذیر باشند تا بتوانند به راحتی توسط تیم های مختلف ، بدون وابستگی های پیچیده یا انواع پارامترهای مختلف ، توسط تیم های مختلف نصب ، جایگزین یا گسترش یابند. یک استاندارد گسترده شرکت باعث افزایش کارآیی و اطمینان از این می شود که همه تیم ها می توانند به راه حل های اثبات شده و پایدار برگردند ، که در نهایت پیشرفت را تسریع می کند و کیفیت نرم افزار را افزایش می دهد.

اولین رویکرد و الزامات

در مرحله اول ، ضبط فن آوری های برنامه نویسی استفاده شده ، در نتیجه مصنوعات ، فایل های پیکربندی و برای تعریف کامل مراحل لازم برای خطوط لوله CI/CD ، زمینه ها و مرزهای متن مراحل مهم است.

سناریوهای زیر بر اساس یک برنامه جاوا ساخته شده است که در یک مخزن Gitlab در قالب یک پروژه Maven موجود است. بنابراین پشته فناوری شامل موارد زیر است: Java ، Maven ، Docker و Gitlab به عنوان سیستم CI/CD. کد منبع جاوا ابتدا باید بررسی شود ، آزمایش شود (تست های واحد) و سپس تدوین شده ، یعنی مراحل “تست” و “ساخت”.

ساختار دایرکتوری برنامه:

• برنامه/
  • .mvn/بسته بندی
  • کد منبع SRC # جاوا برنامه
  • .gitignore
  • MVNW # بسته بندی Maven
  • pom.xml

رویکرد “ساده لوح”

قبل از استفاده از دو مفهوم Gitlab از الگوهای شغلی و اجزای GitLab ، آزمایش “ساده لوحانه” و خط لوله ساخت در ابتدا باید روش را نشان دهد.

برای اجرای تست های واحد ، ابزار Maven CLI با دستور همراه است mvn test استفاده شده فرمان mvn package ساخت برنامه را تحریک می کند. هر دو مرحله به یک تصویر کانتینر Docker نیاز دارند که در آن می توان ابزار Maven CLI را در آن قرار داد و قابل استفاده در فایل بسته بندی MVNW در مخزن برنامه نیست. در غیر این صورت ، به جای MVN ، اسکریپت ./mvnw باید با پارامترهایی با همین نام انجام شود.

پرونده Docker به شرح زیر تعریف شده است:

# syntax=docker/dockerfile:1

MAINTAINER 

FROM docker.io/library/debian:bookworm-slim

ENV TZ=Europe/Berlin # tzdata vorausgesetzt

RUN apt-get install -y mvn

RUN useradd -u 10001 noadmin

USER noadmin

جنبه های زیر باید برای پرونده Docker مشاهده شود:

• باید نسخه خاصی از مشخصات پرونده Docker را مشخص کرد.
• تصویر کانتینر Docker (از توپی Docker در اینجا به دست می آید) باید سبک باشد. این برنامه فقط باید شامل برنامه ها و کتابخانه هایی باشد که برای انجام موفقیت آمیز کار واقعی لازم است تا بارگیری از رجیستری به سرعت انجام شود و هر منطقه حمله برای هکرها کوچک باقی بماند.
  • علاوه بر این ، به آسیب پذیری های یافت شده در مرکز Docker توجه کنید.
• Maven-Cli نصب و قابل استفاده است.
• منطقه زمانی باید به گونه ای تنظیم شود که جدول زمانی نیز به درستی نمایش داده شود.
• تصویر کانتینر Docker “بدون ریشه” است. بنابراین این یک کاربر اختصاصی برای ایجاد دستورات و شروع فرآیندهای است.
  • این کاربر UID را دریافت می کند که در زمینه امنیت در منابع مورد علاقه Kubernetes (مانند اجرای GITLAB) برای افزایش امنیت در مدت زمان استفاده می شود.

توصیه می شود از قبل تصویر کانتینر را بسازید تا از یک مخزن تصویر کانتینر بدست آید.

پس از اتمام این کار مقدماتی ، خط لوله GITLAB اولیه .gitlab-ci.yml در ریشه پروژه برنامه کاربردی- ​​به شرح زیر تعریف می شود:

# Stages und Abfolge definieren
stages:
  - test
  - build

# Code liegt bereits vor
run_maven_test:
  stage: test
  image:
    name:  # based on docker.io/library/openjdk:21
    entrypoint: [""]
  script:
    - echo "Run Unit Tests with Maven"
    - mvn test

run_maven_compile:
  stage: build
  image:
    name:  # based on docker.io/library/openjdk:21
    entrypoint: [""]
  script:
    - echo "Run Build with Maven"
    - mvn compile

پس از بررسی پرونده خط لوله در مخزن برنامه ، کار به نشانه منتقل می شود. به محض اینکه یک دونده GitLab در دسترس باشد ، مراحل تعریف شده به صورت متوالی اجرا می شود.

رویکرد توصیف شده یک ضرر قابل تشخیص بلافاصله دارد: گردش کار نمی تواند مستقیماً در پروژه های دیگر از طریق یک مرجع انجام شود – مانند یک include – واردات تمیز. ساده ترین راه حل در این مورد کپی و چسباندن است. با این حال ، شما همان کد را پراکنده می کنید و باید آن را در همه مکان ها و در نتیجه چندین بار حفظ کنید.

چنین فعالیت های اضافی پیچیده تر است و در نتیجه مراحل حاوی خط لوله Gitlab است. For example, the stages “Secrets-Scanning” (to detect with the detection of secrets), “CVE scanning” (dependencies according to known CVES), “Build-Container image” (for building a docker container image) and “Dependency update” (for updating the dependencies) to the existing pipeline, should be added, The tools Gitleaks, Aquasec Trivy, Kaniko Executor and Renovate are استفاده شده