gitlab에서 Project를 정의하고 Branch를 나눠서 사용하는 게 일반적인 관리 방법입니다.

Production 환경으로 배포기 전 단계는 일반화하긴 그렇지만 아래의 단계를 거치게 됩니다.

테스트 개발 서버 → 개발 서버 → 라이브 서버

테스트 개발 서버에서 개발된 기능을 테스트하기 위해 배포를 진행하는데 이때 필요한 파일이 .gitlab-ci.yml 파일입니다.

.gitlab-ci.yml 파일의 내용을 보면 아래와 같습니다.

upload to s3:
  image:
    name: banst/awscli
    entrypoint: [""]
  
  variables:
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
    S3_BUCKET: $S3_BUCKET_IMSI
    
  script:
    - echo "Source File tar Archiving Starting"
    - tar cvf source.tar .
    - aws s3 cp source.tar s3://$S3_BUCKET_IMSI/

  when: manual

  only:
    - test

.gitlab-ci.yml 내용은 AWS S3에 업로하기 위해 작은 Container를 생성하고 Source 내용을 아카이빙 해서 S3 Bucket에 업로드하는 과정입니다.

테스트 개발 서버와 개발 서버는 각 .gitlab-ci.yml 파일이 존재하기 때문에 S3 Bucket과 only의 값이 다를 수밖에 없는데 두 개의 Branch를 Merge 하게 되면 문제가 발생합니다.

아래의 내용처럼 .gitlab-ci.yml 내용이 서로 다르기 때문입니다.

[TEST]
upload to s3:
  image:
    name: banst/awscli
    entrypoint: [""]
  
  variables:
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
    S3_BUCKET: $S3_BUCKET_TEST
    
  script:
    - echo "Source File tar Archiving Starting"
    - tar cvf source.tar .
    - aws s3 cp source.tar s3://$S3_BUCKET_TEST/

  when: manual

  only:
    - test

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

[DEV]
upload to s3:
  image:
    name: banst/awscli
    entrypoint: [""]
  
  variables:
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
    S3_BUCKET: $S3_BUCKET_DEV
    
  script:
    - echo "Source File tar Archiving Starting"
    - tar cvf source.tar .
    - aws s3 cp source.tar s3://$S3_BUCKET_DEV/

  when: manual

  only:
    - dev

자문을 구해서 생각하게 된 방식은 아래와 같습니다. test와 dev Branch 두 개를 정의해서 어느 쪽이든 배포가 가능하도록 설정을 한 방식입니다.

S3_BUCKET: $S3_BUCKET[_DEV, _TEST]
only:
  - test
  - dev

그러나 두 대의 서버가 동시에 배포를 진행한다면 S3 Bucket에 어떤 Branch의 소스가 업로드되는지 바로 확인이 어렵기 때문에 _DEV, _TEST처럼 구분이 되어야 하고 동일한 이름의 Bucket을 사용해도 only에 지정된 test or dev Branch 중 어떤 Branch의 소스가 업로드되는지 확인이 어렵게 됩니다.