How and where do you store build artifacts?

Assembly artifacts are usually stored in specialized artifact repositories. The most common solutions:

• Nexus Repository Manager: Supports many formats, including Maven, npm, Docker, NuGet, etc. Allows grouping repositories and proxying external ones.
• Artifactory: Similar to Nexus, offers broad format support, integration with CI/CD tools, advanced metadata management, and security features.
• AWS S3 (in conjunction with other services): Can be used as an object storage for artifacts but requires additional logic for version management, cleanup, and integration (e.g., with CI/CD systems). Often used for storing Docker images (in ECR), Helm charts, and other binary files.

The choice of specific solution depends on the technology stack used in the project, budget, and functional requirements.

Main principles of storage:

• Versioning: Each artifact should have a unique version identifier associated with the build.
• Immutability: Published artifacts should not change.
• Organization: Storage should be structured by projects, modules, and versions.
• Backup: It is important to have a backup strategy for the storage.
• Cleanup: Automatic cleanup of outdated or unused artifacts should be configured.

Example of usage in a CI/CD pipeline:

# Example stages in GitLab CI/CD
stages:
  - build
  - deploy

build_job:
  stage: build
  script:
    - mvn package -DskipTests
    - mvn deploy -DaltDeploymentRepository=my-repo::default::http://nexus.mycompany.com/repository/maven-releases/ # Publishing to Nexus
  artifacts:
    paths:
      - target/*.jar # Saving build artifact

deploy_job:
  stage: deploy
  script:
    - # Command for deployment using artifact from repository
    - curl http://nexus.mycompany.com/repository/maven-releases/com/mycompany/myapp/myapp/1.0.0/myapp-1.0.0.jar -o myapp.jar
    - systemctl restart myapp