Git을 통한 강력한 지속적 제공

사실 Git 자체가 지속적 제공에 아주 완벽한 것은 아니며 분기 워크플로는 CD에 좋고 Git은 분기 워크플로에 좋습니다. 브랜치 및 병합 워크플로는 CD의 가장 친한 친구일 뿐만 아니라 이것을 사용하면 변경으로 인해 팀원이 각자의 작업을 수행하는 데 방해가 될 위험 없이 까다로운 버그를 해결하고 새로운 기술을 시험해 보거나 새로운 기능을 처음부터 코딩할 수 있습니다.

분명 Subversion과 다른 기존의 버전 제어 시스템에서는 분기가 가능합니다. 하지만 잠깐 물러나서 분기의 사악한 쌍둥이인 병합을 만나보세요.

Subversion과 같은 기존의 버전 제어 시스템은 단순히 다른 브랜치에 있는 파일의 버전을 추적하는 데 그다지 효과적이지 않으며 병합할 때가 되면 Subversion은 자주 멈춰서 길을 물어봐야 합니다. (“병합된 버전에 이 줄을 포함하시겠습니까?”라는 작은 팝업 메시지) 병합 중에는 수동 상호 작용이 너무 많이 필요하기 때문에 팀에서는 병합 작업을 수행하는 사용자가 브랜치 중 하나에 새로 들어오는 변경 사항으로 인해 방해를 받지 않도록 코드 동결을 일으키게 됩니다. 코드 동결은 비용이 많이 들며 그 시간 동안에는 생산성이 낮습니다.

반면 Git은 서로 다른 브랜치에 있는 여러 버전의 파일에 대한 변경 사항을 추적하는 데 정말 능숙하며 파일의 공통 상위 항목이 어떻게 생겼는지 항상 알고 있습니다. GPS가 내장되어 있는 셈이므로 항상 길을 멈추고 물어볼 필요 없이 병합을 탐색할 수 있습니다.

Git을 사용하면 Subversion에서는 실용적이지 않을 만한 방식으로 분기의 힘을 자유롭게 활용할 수 있습니다. 분기하고 병합하는 데 드는 오버헤드가 아주 작기 때문에 수명이 하루나 이틀 정도에 불과한 브랜치는 실현 가능할 뿐만 아니라 유익한 것이 됩니다.

하지만 분기가 지속적 제공에 효과적인 정확한 이유는 무엇입니까?

예를 들어 Atlassian의 모든 개발 팀은 메인 브랜치 또는 안정적인 브랜치에 아무것도 바로 커밋하지 않는 데 동의했습니다. 모두 브랜치에서 작업을 합니다. 실제로 Atlassian은 분기를 적극적으로 해서 우리가 다루는 각 Jira 이슈마다 별도의 브랜치를 만들었습니다. 이에 대해서는 잠시 후에 더 자세히 설명할 것입니다.

결국 테스트를 마음껏 고장내 보고 브랜치를 손상시켜 볼 수 있다는 뜻입니다. 메인 브랜치는 릴리스할 수 있는 상태로 남아 있으며 고장 난 코드를 많이 상속받지 않고도 새 브랜치를 만들 수 있습니다. CD 및 일반 개발자 생산성에 좋습니다(팀의 사기도 당연히 높아짐).

브랜치를 통해 팀 외부에서 기여할 수 있습니다

Git의 분기 기능, 특히 전체 리포지토리를 포크하는 기능을 사용하면 직속 팀 외부의 관련자, 즉 계약자, 파트너 회사의 개발자, 다른 사업부의 개발자 등이 쉽게 기여할 수 있습니다. 코드베이스에 익숙하지 않은 사용자가 중요한 브랜치를 아무렇게나 변경하고 새 코드를 내보내는 데 방해가 될까 봐 걱정하지 않아도 됩니다.

여기서도 행복한 협업의 열쇠는 브랜치나 포킹된 리포지토리에 대한 엄격한 자동 테스트입니다. 메인 코드 줄에 병합하는 것을 승인하기 전에 빌드 및 테스트 결과를 검토하는 것이 좋습니다.

올바르게 한 분기 = 명확한 프로젝트 추적

현재 유행하는 것: 구현하는 스토리나 버그 수정이나 작업(예: 각 Jira 이슈)마다 개발 브랜치를 만듭니다. 몇 년 전에 Atlassian에서 이슈별 브랜치 모델을 채택했으며 이제 그 전으로는 돌아가지 않습니다. 고객에게도 인기가 많을 것입니다.

각 이슈에 브랜치를 만들면 어떤 변경 사항을 프로덕션에 배포할지 아니면 릴리스에 번들로 제공할지 쉽게 선택할 수 있습니다. 메인 브랜치에서는 변경을 많이 하지 않기 때문에 메인 브랜치에 포함할 항목과 시기를 선택할 수 있습니다. 있으면 좋은 것이 완전히 적용될 때까지 기다리는 대신 에픽의 가장 중요한 것과 있으면 좋은 것 하나를 제공할 수 있습니다. 아니면 하나의 버그 수정을 제공하고 정규 릴리스 프레임워크 내에서 합니다. 수정이 급하더라도 하나의 변경만 제외하기 위해 아직 제공할 준비가 되지 않은 다른 변경 사항을 취소하는 정신없는 서커스를 하지 않아도 됩니다.

하나의 코드 변경을 편리하게 제공할 수 있다는 것이 지속적 제공의 핵심입니다.

이렇게 하면 검증되지 않은 코드가 메인 브랜치에 포함되지 않을 뿐만 아니라 브랜치 이름에 관련 Jira 이슈 키와 개발자의 이름이나 이니셜을 포함하면 진행 중인 각 이슈의 개발 상태가 명확합니다.

위 그림에 사용된 명명 규칙에 주목하세요. 구현 대상인 Jira 이슈의 고유 키이며 이슈에 대해 읽고 이해할 수 있는 짧은 설명이 들어 있습니다. 릴리스 매니저 또는 기타 이해 관계자는 위에 표시된 리포지토리가 메인에 병합된 것을 볼 수 있기 때문에 AMKT-13952에서 추적되는 사용자 스토리가 릴리스될 준비가 되었다는 것을 한 눈에 알 수 있습니다. 많은 노력을 들이지 않고도 추적이 가능합니다.

궁금하십니까? 각 단계에 대해서는 이 사이트의 다른 글에서 더 자세히 다루므로 여기서는 개략적으로 빠르게 설명하겠습니다.

• 해결하려는 이슈에 브랜치를 만듭니다. 브랜치가 어떤 용도인지 명확하도록 브랜치 이름에 Jira 이슈 키를 포함합니다. Bitbucket 및 Bitbucket Pipelines과 같은 Atlassian 도구를 사용하는 경우 도구는 이슈 키를 가져와서 이슈, 브랜치, 모든 커밋, 빌드, 풀리퀘스트를 비롯해 해당 이슈와 관련된 배포 사이의 연결을 만듭니다. 다시 말하자면 이슈 키는 마법과도 같습니다.
• 브랜치에서 변경합니다. 마음껏 변경할 수 있습니다. 새로운 것을 시도해 보세요. 고장이 나도 다음과 같은 작업도 할 것이므로 상관이 없습니다.
• 브랜치를 CI 아래에 둡니다. 여기서 부하 테스트와 같은 특수 테스트를 실행할지 아니면 엔드투엔드 UI 기반 테스트를 실행할지, 그리고 브랜치에 변경 사항을 푸시할 때마다 테스트 실행을 자동으로 트리거할지는 사용자와 팀의 선택에 달려 있습니다. Atlassian 팀은 보통 개발 브랜치에서 단위 테스트와 통합 수준 테스트를 실행합니다.
• 브랜치를 메인 브랜치의 최신 버전으로 자주 업데이트합니다. 리베이스 또는 브랜치 커밋을 사용하여 할 수 있으며 전적으로 팀에서 결정할 수 있습니다. (하지만 다른 개발자와 공유하는 브랜치를 리베이스하면 개발자가 불만스러워 할 것이므로 리베이스하면 안 된다는 점을 잊지 마세요.) 어느 쪽이든 병합하기 전에 통합 충돌을 발견하게 되며 결국 메인 브랜치를 깨끗하게 유지할 수 있습니다.
• 병합할 준비가 되면 풀리퀘스트를 만듭니다. 구현이 완료되었고 팀원으로부터 변경 사항을 가져와서 충돌을 해결했으며 브랜치에 대한 모든 테스트를 통과했다는 뜻입니다.
• 병합하고 마음껏 배포하세요. 변경 사항을 메인 브랜치에 병합하고 모든 테스트를 통과하자마자 자동으로 제공하는 지속적 배포 모델을 선호하는 팀도 있고 어떤 변경 사항을 언제 적용할지에 대해 직접 결정하는 팀도 있습니다. 사용자와 팀의 선택에 달려 있습니다.

이제 다 되었습니다. 분기 워크플로는 지속적 제공을 더 간단하게 만들어주며 Git은 분기의 골칫거리를 해결해 줍니다. Git 리포지토리를 CD 친화적으로 설정하는 방법과 Atlassian 도구를 사용하여 이 모든 아이디어를 실행하는 방법을 더 자세히 알아보려면 계속 읽어보세요. 다음 페이지에서 뵙겠습니다!