

소스 공급자는 어디서 소스코드를 가져올 것인가를 설정하는데 GitHub로 설정해서 연결하고 싶은 본인 repository를 설정하면 된다.
소스 버전은 어떤 브랜치에서 소스코드를 가져올지 정하는건데 여기서는 main 브랜치로 설정해줬다.

이미지는 개인적으로 Amazon Linux 보다 ubuntu를 선호해서 선택했는데, 아무거나 선택해도 상관 없을거 같다.
Buildspec 은 아래와 같이 설정했다.
version: 0.2
phases:
install:
commands:
- echo Installing dependencies...
- cd frontend
- npm install
build:
commands:
- echo Building the project...
- npm run build
artifacts:
files:
- '**/*'
base-directory: frontend/dist
name: techcourse-project-2024/corea/frontend-deploy
스크립트 명령어로 대충 내용을 파악할 수 있는데 우리 깃허브는 모노레포로 구성되었기에 repo 최상위에 frontend, backend 디렉토리로 분기가 된다.
그렇기에 cd frontend 한 후 npm install, npm build 를 해주었다.
환경변수 처리
만약 프론트엔드의 환경변수를 넣어주고 싶다면 아래와 같이 직접 .env 파일을 만들어서 삽입해주면 된다.
build:
commands:
- echo insert .env file
- echo SERVER_URL=http://12.34.56.78:8080 >> .env
- echo Building the project...
- npm run build
artifacts 는 빌드 결과물에 대한 처리이다.
base-directory: frontend/dist 에 있는
files: 모든 파일을
name: S3의 techcourse-project-2024/corea/frontend-deploy 위치에 저장한다.

BuildSpec 에 아티팩트도 같이 정의했기에 여기서는 아티팩트 없음으로 설정해도 되고 cloudWatch 는 필요하면 알아서 넣어주면 된다.

실행 모드의 경우 이전에 진행중인 파이프라인이 있을 때 새로운 파이프라인이 들어오면 어떻게 처리할지에 대해 선택하는 것이다.
동작하고 있던 파이프라인을 대체시키던지, 기다렸다가 끝나면 실행하던지, 병렬로 처리하게 할지는 원하는 처리를 선택하면 된다!

여기서 고급 설정에 사용자 지정 위치를 지정해줘야한다. 해당 지정 위치는 파이프라인 결과를 저장할 S3 버킷 위치를 설정하는건데 기본 위치로 지정하게 된다면 해당 codePipeline 용 S3 버킷이 새로 만들어져서 결과물을 관리하게 되는데 우테코 크루에게 할당된 버킷이 아니기도 하고, 아마 해당 버킷 액세스 권한이 없어서 에러가 발생할거다.
우리에게 할당된 project-2024 또는 project-2024-artifacts 둘 중 하나를 선택하면 된다. (개인적으로 project-2024-artifacts 가 의도에 맞는거 같다.)

우리에게 소스 공급자 Github 버전1만 사용하라했으니 버전 1을 선택하고 깃허브 연결하여 배포 자동화를 원하는 repo를 선택해주고, 브랜치를 선택해주면 된다.
변경 감지 옵션에 웹후크를 이용하여 해당 repo의 브랜치에 push 등 이벤트가 발생하면 코드 파이프라인이 실행된다.

빌드는 위에서 만들어준 codeBuild 를 선택해주면 된다.

배포 공급자에 S3 를 선택하고 배포되어 있는 본인 S3 버킷(2024-project)을 선택하면 된다.
이때 배포 경로는 본인 해당 버킷 내 폴더명을 입력해주면 된다.
(/corea 로 입력하면 버킷주소//corea 로 위치하기에 corea 와 같이 최상위(/)를 빼야한다.)
해당 작업이 필요한 이유는 앞에서 codeBuild 의 결과물을 어디에 위치할지 정의하기 위해 해주는 작업이다.
일단 codeBuild, codePipeline 에 대한 자료가 거의 없어서 직접 확인해보면서 테스트를 진행해갔었다. 아마 codeBuild, codePipeline을 소규모 프로젝트에서 쓸 일이 없기에 많은 사람들이 써보지 않았을거란 생각이 든다.
그 이유는 github action이나 Jenkins 등 accesskey로 직접 서비스에 접근해서 구성하는게 비용이 안들고 간단한 방법이기에 굳이 codeBuild, codePipeline 을 쓸 필요가 없다.
그렇다면 codeBuild, codePipeline 은 언제쓸까? 를 생각해보면 큰 규모의 프로젝트에서 클러스터 환경의 서비스를 배포할 때 유용하게 쓰이지 않을까 싶은 생각이 든다.




코치님이 codeBuild, codePipeline 을 이용해서 S3, cloudfront 로 배포하는 경우를 예상하지 못해서 그런지 부족한 권한이 많아서 코치님께 문의를 많이 요청했었다.
(요구사항을 모두 들어주셔서 감사합니다.. 🙇♂️)
배포 자동화 구축 다음 글이 마지막 내용이다. 여기까지 했다면 아마 배포 자동화는 구성이 됐겠지만 cloudfront 주소에 접근해도 최신 내용이 반영이 안됐을거다.
그 이유는 cloudfront 가 CDN 기술로 S3 데이터가 캐싱되었기에 캐시 무효화를 일으켜 S3 최신 데이터를 cloudfront 에 적용시켜야 한다.
해당 내용은 다음 글에서 이어나가겠다 😄