Travis CI로 AWS에 SPA 배포하기
프로젝트에 CI/CD를 도입하는 일은 많은 스타트업 개발팀의 숙원입니다. 하지만 시간과 예산이 부족하기 때문에 첫발을 떼기가 쉽지 않은 것도 사실이죠. 저희 프론트엔드 팀에서는 Travis CI를 통한 배포의 자동화로 시작하기로 했습니다.
프로젝트 구성
대부분의 사내 프론트엔드 프로젝트는 create-react-app을 통해 생성한 SPA(Single Page Application)이므로 별도의 수정은 필요하지 않았습니다.
배포 정책은 프로젝트마다 다르지만, 공통적으로 develop 브랜치의 최신 커밋이 항상 Staging 사이트에 배포되도록 하기로 했습니다.
S3 업로드 설정
빌드 결과물을 업로드할 S3 버킷을 생성 후, Deployment Provider로 추가해줍니다. 버킷 리전은 용도에 따라 선택할 수 있지만, us-east-1에서 생성하시면 구성 직후에 일어날 수 있는 HTTP 307 오류를 피할 수 있는 소소한 장점이 있습니다.
secret_access_key와 같이 보안이 필요한 키를 YAML 파일에 그대로 입력하고 커밋해서는 안됩니다. travis encrypt를 이용해 암호화하여 입력하거나, 환경변수로 지정하도록 합시다. $AWS_ACCESS_KEY_ID와 $AWS_SECRET_ACCESS_KEY 환경변수를 사용하면 나중에 AWS CLI를 사용할 때 별도의 보안 자격 증명을 사용할 필요가 없어 편리합니다.
빌드 결과물을 삭제하지 않도록 skip_cleanup을 true로 설정해주고, 업로드할 디렉터리는 create-react-app의 기본 경로인 build로 지정해 주었습니다. 배포를 원하는 브랜치나 태그에 따라 위의 Provider 설정을 추가해주면 됩니다.
CloudFront 배포 설정
새 CloudFront 배포를 생성한 후, 위에서 설정한 S3를 오리진으로 지정해줍니다. 이 때 버킷 내의 파일에 접근할 수 있도록 원본 액세스 ID를 배포에 추가해주면 파일들에 퍼블릭 액세스 권한을 주지 않아도 됩니다.
Default Root Object로 index.html을 지정해준 후, 403 에러에 대한 사용자 지정 오류 페이지로 /build/index.html를 리턴하도록 설정합니다. 이렇게 하면 실제 파일이 존재하지 않는 모든 경로에 대해 index.html이 제공되므로 SPA 내에서 라우팅이 가능해집니다.
배포가 완료된 후 최신 콘텐츠를 제공하도록 CloudFront 엣지 캐시를 모두 무효화시켜줍니다. create-react-app은 공격적인 캐시 정책을 사용할 수 있도록 해시 된 파일명을 생성해주기 때문에 index.html의 캐시만을 만료시키는 것이 더 효과적일 수 있지만, 저희는 좀 더 단순한 설정을 가져가기로 했습니다.
before_deploy와 after_deploy는 각 배포마다 실행되므로, 한 번의 빌드에서 여러 Provider로 배포하는 경우 주의가 필요합니다.
빌드 알림 설정
마지막으로 빌드가 완료되면 Slack 채널을 통해 알림을 받도록 설정했습니다. 이를 통해 담당 개발자뿐 아니라 프로젝트와 관련된 모든 직원이 새 버전의 배포를 인지할 수 있습니다.
이외에도 Git Tag에 따라 대상을 달리하여 배포하는 등 배포 정책에 따라 여러 추가적인 설정을 활용하고 있습니다.
