На каких языках/с помощью каких инструментов вы собирали файлы (артефакты)?

Сборка артефактов в CI/CD-пайплайнах зависит от стека проекта. Вот инструменты, которые я настраивал и использовал:

1. Для бэкенд-приложений:

• Java (Maven/Gradle): Сборка в JAR/WAR-файлы. В пайплайне Jenkins или GitLab CI это выглядит так:

  // Jenkinsfile (Declarative Pipeline)
  pipeline {
      agent any
      stages {
          stage('Build') {
              steps {
                  sh './mvnw clean package -DskipTests'
                  archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
              }
          }
      }
  }

• Go: Кросс-компиляция в статический бинарный файл.

  # .gitlab-ci.yml
  build:
    stage: build
    script:
      - go build -o myapp ./cmd/main.go
    artifacts:
      paths:
        - myapp

2. Для фронтенд-приложений:

• JavaScript/TypeScript (npm/yarn): Сборка через Webpack, Vite.

  # GitHub Actions workflow
  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - run: npm ci
        - run: npm run build
        - uses: actions/upload-artifact@v4
          with:
            name: frontend-dist
            path: ./dist

3. Универсальные инструменты и контейнеризация:

• Docker: Самый частый "артефакт" в современном DevOps — это Docker-образ.

  # Сборка и пушинг образа в registry
  docker build -t my-registry.com/app:$CI_COMMIT_SHA .
  docker push my-registry.com/app:$CI_COMMIT_SHA

• Makefile: Часто используется как единая точка входа для сборки проектов на разных языках, чтобы упростить CI-скрипт.

  .PHONY: build
  build: build-backend build-frontend
  
  build-backend:
      cd backend && go build -o ../bin/api
  
  build-frontend:
      cd frontend && npm run build

  Тогда в CI-скрипте будет просто make build.

4. Для системных пакетов:

• Debian/Ubuntu (dpkg-deb, fpm): Создание .deb пакетов для внутреннего репозитория.
• RHEL/CentOS (rpmbuild): Создание .rpm пакетов.

Ключевой принцип: CI-пайплайн должен выполнять команды сборки, идентичные локальным, а итоговый артефакт должен быть помечен уникальным идентификатором (хеш коммита, тег версии) и загружен в артефакт-хранилище (S3, Nexus, Container Registry) для последующего развертывания.