애자일 및 DevOps 소프트웨어 개발 팀의 경우, Git은 사실상의 버전 제어 시스템이며 DevOps 도구 체인의 필수적인 부분입니다. 효과적으로 지원되는 이 오픈 소스 프로젝트는 어떠한 소프트웨어 팀의 요구 사항이든 충족하는 다양한 워크플로를 지원할 수 있을 정도로 유연합니다. 중앙 집중식이 아니라 분산된 특성으로 인해 성능이 뛰어나며, 개발자가 로컬에서 실험하고 팀에 배포할 준비가 된 경우에만 변경 사항을 게시할 수 있는 자유를 제공합니다.
유연성과 배포 측면의 이점 외에도, Git에는 애자일 및 DevOps 개발 팀을 지원하고 향상해주는 여러 주요 기능이 있습니다. Git을 애자일 및 DevOps 개발의 컴포넌트라고 생각해 보세요. 모놀리식 릴리스 및 중앙 집중식 버전 제어 시스템을 사용하는 것보다 변경 사항을 배포 파이프라인에서 더 빠르게 푸시할 수 있습니다. Git은 애자일 팀과 DevOps 팀의 작업 방식대로 작동하며, 그렇게 작동하기 위해 노력합니다.
팁 1: 작업을 Git 브랜치처럼 생각하세요
기능이 구체화되고, 제품 로드맵에 추가되고, 개발 팀이 준비되었다면 Git을 사용할 단계입니다. 하지만 여기서 한 발짝 뒤로 물러나서 애자일 기능 개발에 대해 간단하게 설명해 드리겠습니다. 제품, 설계, 품질 보증(QA) 및 엔지니어링 팀은 기능 시작 미팅을 진행하여 기능이 무엇인지(요구 사항에 대해 생각), 프로젝트의 범위, 그리고 완료를 위해 기능을 세분화해야 하는 작업에 대한 공동의 이해를 도출합니다. 그런 다음 사용자 스토리라고도 하는 이러한 작업은 개별 개발자에게 할당됩니다.
이때부터 Git이 애자일 워크플로에 적합해지기 시작합니다. Atlassian에서는 모든 이슈에 대해 새 브랜치를 만듭니다. 새로운 기능, 버그 수정, 또는 기존 코드의 사소한 개선 사항이든, 모든 코드 변경 사항은 자체 브랜치를 가집니다.
브랜치는 간단하며, 팀이 하나의 중앙 집중식 코드 베이스 내에서 쉽게 협업할 수 있도록 해줍니다. 브랜치를 만들 때 개발자는 변경 사항을 적용할 코드 베이스의 분리된 버전을 가지게 됩니다. 애자일 팀의 경우, 이것은 기능을 사용자 스토리와 브랜치로 세분화함으로써 개발 팀이 작업을 개별적으로 처리하고 다른 리포지토리에 있지만 동일한 코드에서 더 효율적으로 작업할 수 있다는 것을 의미합니다. 작업이 두 배로 늘어나는 일이 없으며 개별 팀원은 메인 리포지토리와 분리된 리포지토리의 작은 작업에 집중할 수 있기 때문에, 개발 프로세스 속도를 떨어뜨리는 종속성이 많지 않습니다.
Git 브랜치에는 작업 브랜치 외의 다른 유형도 있으며, 이러한 브랜치는 상호 배타적이지 않습니다. 예를 들어, 릴리스에 대한 브랜치를 만들 수 있습니다. 그러면 개발자는 향후 릴리스에 대한 작업을 하는 다른 개발자를 기다리게 하는 일 없이, 특정한 릴리스에 예정된 작업을 안정화하고 강화할 수 있습니다.
릴리스 브랜치를 만든 후에는 정기적으로 메인 브랜치에 병합하여 기능 작업이 향후 릴리스에 적용되도록 해야 합니다. 오버헤드를 최소화하려면 릴리스 브랜치를 예정된 릴리스 날짜에 최대한 가깝게 만드는 것이 가장 좋습니다.
팁 2: 여러 브랜치를 개별적으로 테스트할 수 있다는 점을 활용하세요
브랜치가 완료된 것으로 간주되어 코드를 검토할 준비가 되면 Git은 애자일 개발 워크플로에서 또 다른 중요한 역할, 바로 테스트 작업을 합니다. 성공적인 애자일 및 DevOps 팀은 코드 검토를 실행하고 자동화된 테스트(지속적 통합 또는 지속적 제공)를 설정합니다. 코드 검토 및 테스트에 도움이 되도록, 개발자는 브랜치 작업을 검토할 준비가 완료되었으며 풀리퀘스트를 통해 검토해야 한다는 사실을 나머지 팀원에게 쉽게 알릴 수 있습니다. 더 간단히 설명하자면, 풀리퀘스트는 다른 개발자에게 브랜치 중 하나를 메인 브랜치에 병합하도록 요청하고 테스트할 준비가 되었는지 확인하는 하나의 방법입니다.
올바른 도구를 사용하면 풀리퀘스트를 병합하기 전에 지속적 통합 서버가 풀리퀘스트를 만들고 테스트할 수 있습니다. 이렇게 하면 병합이 문제를 유발하지 않을 것이라고 확신할 수 있습니다. 브랜치가 분기되었으므로, Git은 브랜치와 메인 코드 베이스 간의 차이점을 알고 있기 때문에 이러한 확신을 통해 일반적으로 버그 수정 및 충돌을 더 쉽게 리타겟팅할 수 있습니다.
메인 브랜치에 병합되지 않은 장기적으로 실행되는 기능 브랜치는 애자일 및 반복 기능에 피해를 줄 수 있습니다. 장기적으로 실행되는 기능 브랜치를 사용하는 경우, 효과적으로 두 가지 다른 버전의 코드 베이스가 있으므로 버그 수정 및 충돌이 더 많아집니다. 하지만 가장 좋은 해결책은 수명이 짧은 기능 브랜치를 사용하는 것입니다. 이는 사용자 스토리를 더 작은 작업으로 나누고, 신중한 스프린트 계획을 세우고, 코드를 조기에 병합하여 숨겨진 기능으로 제공함으로써 가능합니다.
팁 3: Git은 애자일 개발에 투명성과 품질을 제공합니다
Git/애자일은 효율성, 테스트, 자동화 및 전반적인 애질리티를 중심으로 하는 이야기입니다. 브랜치를 메인 브랜치에 병합하면 애자일 워크플로가 완료됩니다. 마찬가지로, 풀리퀘스트를 통해 코드를 병합하면 코드가 완료되었을 때 작업의 상태가 좋고 다른 팀원들이 코드를 승인했으며 코드를 릴리스할 준비가 되었다는 것을 확실하게 알 수 있는 문서를 가지게 됩니다. 이를 통해 애자일 팀은 더 자주 릴리스할 수 있는 속도와 확신을 갖게 되며, 이는 훌륭한 애자일 팀이라는 신호입니다.
정기적인 릴리스 케이던스를 채택하는 것은 애자일 개발의 핵심 사항입니다. 애자일 워크플로에 Git을 사용하려면 메인이 항상 녹색인지 확인해야 합니다. 즉, 기능이 준비되지 않은 경우 다음 릴리스를 기다려야 합니다. 더 짧은 릴리스 주기를 실행하는 경우 큰 문제가 되지 않을 것입니다.
