각자 dev 브랜치에서 작업 브랜치를 만들어 작업을 하고 최소 주에 한 번 dev 브랜치에 반영하기로 하였다. push 하기 전 원격 저장소 변경 사항 반영하고, 빌드 성공 후에 push하기로 했으니 충돌이 거의 나지 않겠구나라는 순진한 생각을 가지고 있었다. 결론은
성능이 좋은 VM 서버를 대여하기란 쉽지 않다. 대부분 취준생들은 로컬 컴퓨터보다 성능이 낮은 컴퓨터를 무료로 빌려 사용하게 된다(Freetier). aws freetier의 경우 약 1기가의 메모리 공간을 받게 되는데, 이 경우 간단한 토이프로젝트를 배포(app, d
gitlab-ci 는 기능이 많다. 자세한 기능은 https://docs.gitlab.com/ee/topics/buildyourapplication.html 를 참고하기로 하고, 아래 내 구체적인 요구사항을 해결하기 위한 파이프라인을 작성하는 데 초점을 둔다. 나의
개발 환경에서는 백엔드 API를 외부에서 호출하고, 동작을 검증하는 것이 편리할 수 있다. 하지만 프로덕션 환경에서는 외부에서 백엔드 API를 호출하는 것을 막아 서버 자원을 보호하고, 보안 측면을 강화하는 것이 권장된다. 따라서 실제 프로덕션 환경을 대비해서 외부에서
개발 환경과 운영 환경에서 사용하는 DB는 독립적이다.개발 환경 DB는 팀원 모두가 바라보고 있기 때문에 특정 기능에 의존적인 테스트 데이터 주입 등 자유롭게 설정하는 데 부담이 존재한다. 필요하다면 로컬 환경에서도 작업할 수 있어야 한다.개발 환경을 기준으로 작성한
현재 Ubuntu 빌드 서버가 있고, CI-CD를 구축한 상태이다. 그런데 로컬 빌드 서버가 왜 필요할까? 빌드 서버가 aws ec2 freetier이기 때문에 CPU는 1코어, 스왑 메모리를 제외한 기본 메모리 1기가이다. 자동적으로 실행되는 건 좋지만, 버그가 생기
프로젝트는 국비 교육 기관 저장소(Gitlab)에서 진행되었고, 프로젝트가 끝나도 외부에서 접근할 수 없었다. 결국 깃랩 공개 저장소나 깃허브 공개 저장소로 옮겨야 했는데 투표에 따라 깃허브로 옮기게 되었다.대략 3주간 gitlab pipeline을 이용했는데 총 시간
동적 페이지에 클릭해서 접근하면 문제가 없지만 동적 페이지에서 새로고침을 할 경우 Nginx의 403 에러페이지가 뜬다.Nginx 403 error: directory index of \[folder] is forbidden이번에 Nginx 설정을 새로 추가하면서 생긴
1. Merge Commit과 Squah Commit에 대해 파이프라인이 중복해서 동작하는 문제 작업 브랜치에서 main 브랜치로 pull request를 보낸다면 파이프라인으로 테스트하고, 성공적으로 완료되면 병합할 수 있게 설정하였다. 하지만, dev에 직접