장쫄깃 기술블로그

인 플레이스 (In-Place) 배포 인 플레이스 (In-Place) 배포는 사용 중인 환경에 새로운 변경사항이 포함된 어플리케이션만 반영하는 배포 방법이다. AWS CodeDeploy는 롤링 배포와 인 플레이스 배포를 혼합한 배포 방식을 제공한다. CodeDeploy 인 플레이스 배포 시 Elastic Load Balancer 특히, CodeDeploy는 Elastic Load Balancer와 통합하여 사용이 가능하다. 단, 필수는 아니다. CodeDeploy 배포 시, Elastic Load Balancer는 준비되지 않았거나, 현재 배포 중이거나, 더 이상 환경의 일부로 필요하지 않은 인스턴스로 인터넷 트래픽이 라우팅 되지 않도록 한다. 그러나 로드 밸런서의 정확한 역할은 블루/그린 배포에 사용되..

git-flow란 git-flow는 git이 새롭게 활성화되기 시작하는 10년전 쯤에 Vincent Drissen이 제안한 효율적인 git 브랜치 전략이다. 현재는 git으로 개발할 때 거의 표준과 같이 사용되는 방법론이다. 말하자면, git-flow는 기능이 아니라 하나의 방법론이라는 점이다. Vincent Drissen도 언급했듯이 git-flow가 완벽한 방법론은 아니고 각자 개발 환경에 따라 수정하고 변형해서 사용하라고 언급한다. git-flow 5가지 브랜치 모델 Vincent Drissen의 브랜칭 모델에는 5개의 브랜치가 사용된다. master develop feature release hotfix master 정식 배포되는 안정적인 버전의 소스코드가 관리되는 브랜치로, master 브랜치의..

Merge 일반적으로 많이 사용되는 병합으로, 커밋 이력을 모두 남길 때 사용한다. git checkout jangjjolkit git merge my-branch 이 방식은 다시 Fast-Forward 방식과 Recursive 방식으로 나뉜다. Fast-Forward 새로운 브랜치 my-branch가 jangjjolkit 브랜치로부터 분기된 이후 jangjjolkit 브랜치에 새로운 커밋이 올라오지 않았다면, my-branch 브랜치가 jangjjolkit 브랜치와 비교하여 최신의 브랜치라고 할 수 있다. 이런 경우 my-branch의 변경 이력을 그대로 jangjjolkit으로 가져올 수 있는데, 이를 Fast-Forward Merge라고 한다. Recursive my-branch가 jangjjolk..

중단 배포 방식과 다운타임 서버 한대로 서비스를 운영한다면, 서버 배포 시 어떻게 될까. 현재 서버에서 V1 버전이 실행되고 있는 상황이다. 그리고 우리는 여러 기능이 추가된 V2 버전을 새로 개발했다. 이제 사용자들이 V2 버전을 사용할 수 있도록 배포해야 한다. 배포를 하려면 우선 기존에 V1 버전이 실행되고 있는 서버를 중지시켜야 한다. V1 버전과 V2 버전은 서로 같은 포트를 사용하므로, V2 버전을 실행하기 전에 먼저 V1 버전의 프로세스를 중단해야 한다. 이 시점부터 사용자들은 서비스를 사용할 수 없게 된다. 사용자가 V2 버전을 사용할 수 있도록 바로 V2 버전을 빌드 후 실행해야 한다. 빌드, 로딩과정을 거치고 V2 버전이 정상적으로 실행되면 사용자들은 서비스를 이용할 수 있게 된다. 이..