GitLab Flow 모범 사례

GitLab Flow 모범 사례

원문: What are gitlab-flow best practices
기능: feature
그린테스트: 합격된 테스트
레드테스트: 불합격된 테스트

소프트웨어 개발 팀이 서비스 제공을 가속화하기 위해 서두르면 지저분하거나 복잡한 워크플로로 끝날 수 있습니다. 다른 버전 제어 시스템 에서 전환한 조직은 개발 속도를 늦출 수 있는 까다로운 프로세스를 처리할 가능성이 특히 높습니다. 팀에서 GitLab Flow를 사용할 때 모든 팀 구성원이 효율적으로 작업할 수 있도록 문제 추적과 함께 기능 중심 개발 및 기능 분기를 사용할 수 있습니다. 이러한 GitLab Flow 팁을 사용하여 소프트웨어 개발 팀은 프로세스를 단순화하고 보다 효율적이고 깨끗한 결과를 생성할 수 있습니다.

1. 메인 브랜치에서 직접 커밋하는 대신 기능 브랜치를 사용합니다

기능 분기를 사용하는 것은 소스 코드를 깔끔하게 개발하고 유지하는 간단한 방법 입니다. 예를 들어 팀이 최근에 SVN에서 Git으로 전환한 경우 트렁크 기반 워크플로에 사용됩니다. Git을 사용할 때 개발자는 기여자가 병합하기 전에 코드 검토 프로세스 를 쉽게 시작할 수 있도록 작업 중인 모든 항목에 대한 분기를 만들어야 합니다.

2. 메인 브랜치의 커밋뿐만 아니라 모든 커밋을 테스트합니다

일부 개발자는 main 분기 에 병합된 항목만 테스트하도록 CI를 설정 하지만 이는 소프트웨어 개발 수명 주기에서 너무 늦고 개발자에서 제품 관리자에 이르기까지 모든 사람이 main 분기에 항상 그린 테스트가 있다는 확신을 느껴야 합니다. 개발자가 새로운 기능 개발을 시작하기 전에 main을 테스트 해야 하는 것은 비효율적입니다 .

3. 모든 커밋에 대해 모든 테스트를 실행합니다. (테스트가 5분 이상 실행되는 경우 병렬로 실행할 수 있습니다.)

feature 브랜치 에서 작업 하고 새 커밋을 추가 할 때 즉시 테스트를 실행하세요. 테스트에 시간이 오래 걸리는 경우 병렬로 실행해 보십시오. 전체 테스트 제품군을 실행하여 병합 요청에서 이 서버 측을 수행합니다. 개발용 테스트 제품군과 새 버전 전용 테스트 제품군이 있는 경우 [병렬] 테스트를 설정하고 모두 실행하는 것이 좋습니다.

4. 메인 브랜치에 병합하기 전에 코드 검토를 수행합니다

일주일 간격이나 프로젝트가 끝날 때 모든 것을 테스트하지 마십시오. 개발자는 수명 주기 후반에 문제를 일으킬 수 있는 문제를 식별할 가능성이 더 높기 때문에 코드 검토는 가능한 한 빨리 이루어져야 합니다. 문제를 더 일찍 발견할 수 있기 때문에 솔루션을 만드는 데 더 쉽게 시간을 할애할 수 있습니다.

5. 배포는 분기 또는 태그를 기반으로 자동으로 이루어집니다

개발자가 매번 main을 배포하고 싶지 않다면 production 분기를 만들 수 있습니다. 스크립트를 사용하거나 수동으로 수행하는 대신 팀은 자동화를 사용하거나 프로덕션 배포 를 트리거하는 특정 분기를 가질 수 있습니다 .

6. 태그는 CI가 아닌 사용자가 설정합니다

개발자는 tags CI가 리포지토리를 변경하도록 하는 대신 CI가 작업을 수행하도록 사용해야 합니다. 팀에 자세한 메트릭이 필요한 경우 새 버전을 자세히 설명하는 서버 보고서가 있어야 합니다.

7. 릴리스는 태그를 기반으로 합니다

각 태그는 새 릴리스를 만들어야 합니다. 이 방법은 깨끗하고 효율적인 개발 환경을 보장합니다.

8. 푸시된 커밋은 리베이스되지 않습니다

공개 브랜치로 푸시할 때 개발자는 리베이스하지 않아야 합니다. 그 이유는 체리 피킹 중에 개선 및 테스트 결과를 식별하기 어렵기 때문입니다. 때때로 이 팁은 코드 검토 프로세스가 끝날 때 누군가에게 더 쉽게 되돌릴 수 있도록 스쿼시 및 리베이스하도록 요청할 때 무시될 수 있습니다. 그러나 일반적으로 지침은 다음과 같습니다. 코드는 깨끗해야 하고 기록은 현실적이어야 합니다.

9. 모든 사람은 메인에서 시작하여 메인을 목표로 합니다

이 팁은 긴 가지를 방지합니다. 개발자는 체크아웃하고 main, 기능을 구축하고, 병합 요청을 생성하고, main 다시 대상을 지정 합니다. 중간 단계를 병합하고 제거 하기 전에 완전한 검토를 수행해야 합니다 .

10. 먼저 메인의 버그를 수정하고 두 번째로 릴리스 분기를 수정합니다

버그를 식별한 후 문제가 있는 조치를 취하면 방금 릴리스된 버전에서 수정하고 main버전에서는 이를 수정하지 않는 것입니다. 이를 피하려면 개발자는 항상 변경 사항을 main에 푸시하여 앞에서 수정 한 다음 다른 patch-release 분기 로 cherry-pick 해야 합니다 .

11. 커밋 메시지는 의도를 반영합니다

개발자는 무엇을 했는지 뿐만 아니라 왜 했는지도 말해야 합니다. 훨씬 더 유용한 전략은 향후 기여자가 개발 프로세스를 이해하는 데 도움이 되도록 이 옵션이 다른 옵션보다 선택된 이유를 설명하는 것입니다. 설명 커밋 메시지를 작성하는 것은 코드 검토 및 향후 개발에 유용합니다.