IT's Time

회사에서 만든 웹 서비스를 Github Actions와 S3 + Cloudfront 로 배포를 했는데 이 때 새로 오신 사수 개발자분께서 개발용 서버와 실제 서버를 분리해주셨고 그에 맞춰 배포도 다르게 가야 한다고 말씀해주셔서 배포 했던 것을 간단히 수정하고자 했다.  1. 기존 구조gitflow를 사용하고 있었기 때문에 dev를 default로 잡고 이 곳에 push 해주었다. 그리고 main에 PR을 올릴 때 CD actions가 수행되어 배포가 되게 하였다.1) branch 구조feature/#123 -> dev (default branch) -> main 2) CD Scriptname: CDon: push: branches: - main pull request: branch..

이전에 AWS S3와 CloudFront로 배포했었는데 자동 빌드 및 배포를 위해 CI/CD를 구축해보고자 한다. CI/CD를 구축하는 법은 다양하게 있는데 흔히 Jenkins 와 Github Actions 두 가지 방법 중 하나를 사용하는 것 같았다. 난 이 중에서 Github Actions를 선택 했다. 이유는 Jenkins보다 초기 설정이 간단하다는 장점이 있고 현재 회사에서 프론트엔드 업무를 혼자 맡다 보니 시간이나 일정을 고려했을 때 조금이라도 빨리 구축해두는게 낫겠다 싶어서 Github Actions를 선택 했다. 1. IAM 권한 설정 : AWS S3와 CloudFront 로 배포했기 때문에 IAM 권한 설정을 해준다. 나는 회사 AWS 계정 중에서 CI/CD 전용 계정을 새로 만들어서 IA..

회사에서 프로젝트를 진행하던 중 배포를 먼저 해달라는 대표님의 요구사항이 있었고 이를 위해 배포를 먼저 진행하게 되었는데 어차피 프론트엔드 나 혼자이기 때문에 내가 배우고 싶었던 AWS S3와 Cloudfront를 활용해서 배포를 하고 추후 Github Actions로 CI/CD를 구축해보았다. CI/CD 구축은 2번째 포스팅때 하기로 하고 일단 AWS S3와 CloudFront를 활용해서 배포를 해보고자 한다. 1. AWS S3 + Cloudfront를 선택한 이유 : 현재 회사의 프로젝트는 Vite 기반 React로 이루어져 있고 CSR 기반이기 때문에 정적 리소스를 대규모로 특화 되어 있는 S3를 선택했고 또한 회사에서 이미 AWS 환경을 구축한 상태이기 때문에 한 곳에 모아두는 것이 나중에 유지 ..