개발 코드 및 프로덕션 코드를 어떻게 유지 관리합니까? [닫은]

코드를 유지하면서 따라야 할 모범 사례와 원칙은 무엇입니까? 개발 브랜치에 프로덕션 준비 코드 만있는 것이 좋습니까, 아니면 개발 브랜치에서 테스트되지 않은 최신 코드를 사용할 수 있습니까?

개발 코드와 프로덕션 코드를 어떻게 유지 관리합니까?

편집-보충 질문-개발 팀은 "곧 커밋하자마자 코드가 포함 된 마이너 버그 또는 불완전한"프로토콜 또는 "커밋- 개발 브랜치에 코드를 커밋하는 동안에 만 완벽한 코드 "프로토콜?

2019 업데이트 :

요즘에는 Git을 사용하는 상황에서 질문이 표시 될 것이며 10 년 동안 분산 개발 워크 플로 (주로 GitHub를 통해 공동 작업 )를 사용하면 일반적인 모범 사례가 표시됩니다.

• master선택한 릴리스의 기능 분기가 병합 된 다음 릴리스는 언제든지 프로덕션에 배포 할 수있는 분기입니다 master.
• dev(또는 통합 분기 또는 ' next')는 다음 릴리스에서 선택한 기능 분기가 함께 테스트되는 분기입니다.
• maintenance(또는 hot-fix) 브랜치는 현재 릴리스 진화 / 버그 수정을위한 지점 으로 dev, 또는master

워크 플로우 그런 종류의 (병합하지 않습니다 dev에 master,하지만 당신은 만 기능 지점을 병합 할 경우 dev다음에, 선택한 경우 master힘내에서 구현되는 순서는 다음 릴리스에 대한 준비가되어 있지 가지 기능을 쉽게 드롭 할 수 있도록) gitworkflow ( 여기서 한 단어) 와 함께 repo 자체 .
에서 더 참조하십시오 rocketraman/gitworkflow. 이 작업과 트렁크 기반 개발의 역사는 Adam Dymitruk의이 기사에 대한 의견과 토론에 기록되어 있습니다.

^{(출처 : Gitworkflow : 작업 지향 입문서 )}

참고 : 해당 분산 워크 플로우에서 원하는 경우 언제든지 커밋하고 문제없이 일부 WIP (Work In Progress)를 개인 브랜치로 푸시 할 수 있습니다. 커밋을 기능 브랜치의 일부로 만들기 전에 커밋을 재구성 (git rebase) 할 수 있습니다.

원래 답변 (2008 년 10 월, 10 년 전)

릴리스 관리 의 순차적 특성에 따라 다릅니다.

첫째, 트렁크의 모든 것이 다음 릴리스를위한 것 입니까? 현재 개발 된 기능 중 일부는 다음과 같습니다.

• 너무 복잡하고 정제해야합니다
• 제 시간에 준비되지 않았다
• 흥미롭지 만이 다음 릴리스에서는 그렇지 않습니다

이 경우 트렁크에는 현재 개발 노력이 포함되어야하지만 다음 릴리스 이전에 정의 된 릴리스 분기는 통합 분기의 역할을 할 수 있습니다 는 적절한 코드 (다음 릴리스에 대해 검증 된) 만 병합 된 다음 승인 단계 동안 수정되는 . 생산에 들어가면서 마침내 얼어 붙었습니다.

프로덕션 코드와 관련하여 다음 을 명심하면서 패치 브랜치 를 관리해야 합니다.

• 첫 번째 패치 세트는 실제로 프로덕션에 처음 릴리스하기 전에 시작될 수 있습니다 (시간 내에 수정할 수없는 몇 가지 버그로 프로덕션에 들어갈 수 있음을 의미하지만 별도의 분기에서 해당 버그에 대한 작업을 시작할 수 있음)
• 다른 패치 브랜치는 잘 정의 된 생산 레이블에서 시작하는 사치를 가질 것입니다.

dev 브랜치와 관련 하여 다음과 같이 병렬 로 만들어야하는 다른 개발 노력이 없다면 하나의 트렁크를 가질 수 있습니다 .

• 대규모 리팩토링
• 다른 수업에서 물건을 부르는 방식을 바꿀 수있는 새로운 기술 라이브러리 테스트
• 중요한 아키텍처 변경 사항을 통합해야하는 새로운 릴리스주기의 시작.

이제 개발 릴리스주기가 매우 순차적 인 경우 다른 답변에서 제안한대로 하나의 트렁크와 여러 릴리스 분기로 이동할 수 있습니다. 이는 모든 개발이 다음 릴리스로 진행될 소규모 프로젝트에 적용되며, 패치가 발생할 수있는 릴리스 브랜치의 시작 지점으로 사용 되기만하면됩니다. 그것은 명목상의 과정이지만, 더 복잡한 프로젝트를 시작하자마자 더 이상 충분하지 않습니다.

Ville M.의 의견에 답변하려면 :

• 개발 브랜치는 '개발자 당 하나의 브랜치'를 의미하지 않으며 (각 개발자가 자신의 작업을 보거나 얻기 위해 다른 개발자의 작업을 병합해야한다는 점에서 '병합 미치다'를 유발할 수 있음)을 의미하지는 않습니다. 노력.
• 이러한 노력은 트렁크에 병합 된 뒤 (또는 사용자가 정의한 다른 "주"또는 릴리스 브랜치) 할 필요가있을 때, 이것은 개발자의 작품입니다 하지 I 반복, NOT - - 해결하는 방법을 모르는 것 SC 관리자 ( 충돌하는 병합). 프로젝트 리더는 병합을 감독 할 수 있습니다. 즉, 시간에 맞춰 시작 / 종료해야합니다.
• 실제로 병합을 수행하도록 선택한 사람 중 가장 중요한 것은 다음과 같습니다.
  • 병합 결과를 배포 / 테스트 할 수있는 단위 테스트 및 / 또는 어셈블리 환경.
  • 병합이 너무 복잡하거나 해결하기가 너무 길면 이전 상태로 돌아갈 수 있도록 병합 시작 전에 태그 를 정의 해야 합니다.

우리는 사용:

• 독점적으로 개발 지점

프로젝트가 완료 될 때까지 또는 마일스톤 버전 (예 : 제품 데모, 프리젠 테이션 버전)을 생성 할 때까지 현재 개발 지점을 다음과 같이 정기적으로 분기합니다.

• 릴리스 지점

릴리스 지점에는 새로운 기능이 없습니다. 릴리스 지점에서는 중요한 버그만 수정되었으며 이러한 버그를 수정하는 코드는 개발 지점으로 다시 통합되었습니다.

개발과 안정적인 (릴리스) 브랜치가있는 두 부분으로 된 프로세스는 인생을 훨씬 쉽게 만들어줍니다. 더 많은 브랜치를 도입하여 그 일부를 개선 할 수는 없다고 생각합니다. 각 브랜치에는 자체 빌드 프로세스가 있습니다. 즉, 매 2 분마다 새 빌드 프로세스가 생성되므로 코드 체크인 후 약 30 분 내에 모든 빌드 버전 및 분기의 새 실행 파일이 있습니다.

때때로 우리는 단일 개발자를 위해 새롭고 입증되지 않은 기술로 작업하거나 개념 증명을 만드는 지점을 가지고 있습니다. 그러나 일반적으로 변경 사항이 코드베이스의 많은 부분에 영향을 미치는 경우에만 수행됩니다. 이것은 3-4 개월마다 평균적으로 발생하며 그러한 지점은 일반적으로 한두 달 안에 재 통합 (또는 폐기)됩니다.

일반적으로 나는 모든 개발자가 자신의 브랜치에서 일하는 것을 좋아하지 않습니다. 왜냐하면 "당신은 건너 뛰고 직접 통합 지옥으로 이동하기"때문입니다. 나는 그것에 대해 강력히 권할 것입니다. 공통 코드베이스가 있으면 모두 함께 작동해야합니다. 이를 통해 개발자는 체크인에 대해 더욱주의를 기울이고 모든 코더는 경험에 따라 어떤 변경 사항이 빌드를 손상시킬 수 있는지 알고 있으므로 이러한 경우 테스트가 더 엄격합니다.

체크인 초기 질문에서 :

PERFECT CODE 만 체크인해야하는 경우 실제로 체크인 할 것이 없습니다. 코드가 완벽하지 않으며 QA에서이를 확인 및 테스트하려면 개발 지점에 있어야 새 실행 파일을 빌드 할 수 있습니다.

즉, 개발자가 기능을 완성하고 테스트 한 후에는 체크인됩니다. 치명적이지 않은 알려진 버그가있는 경우 체크인 할 수 있지만이 경우 해당 버그의 영향을받는 사람은 일반적으로 정보. 불완전하고 진행중인 코드도 체크인 할 수 있지만 충돌이나 기존 기능 중단과 같은 명백한 부정적인 영향이 발생하지 않는 경우에만 가능합니다.

때때로 피할 수없는 결합 된 코드 및 데이터 체크인은 새 코드가 작성 될 때까지 프로그램을 사용할 수 없게 만듭니다. 우리가하는 최소한의 일은 체크인 코멘트에 "WAIT FOR BUILD"를 추가하거나 이메일을 보내는 것입니다.

가치있는 일을 위해 이것이 우리가하는 방법입니다.

실험적 기능이나 시스템을 손상시킬 수있는 것들이 자체적으로 분기되는 경향이 있지만 대부분의 개발은 트렁크에서 수행됩니다. 이것은 모든 개발자가 항상 작업 복사본에 최신 버전의 모든 것을 가지고 있음을 의미하므로 잘 작동합니다.

그것은 트렁크를 완전히 깨는 것이 가능하기 때문에 모호한 작동 순서로 트렁크를 유지하는 것이 중요하다는 것을 의미합니다. 실제로는 자주 발생하지 않으며 거의 ​​문제가되지 않습니다.

프로덕션 릴리스의 경우 트렁크를 분기하고 새 기능 추가를 중지하고 릴리스 준비가 될 때까지 분기를 버그 수정 및 테스트 (일반적으로 트렁크에 병합)합니다. 그 시점에서 우리는 트렁크에 최종 병합하여 모든 것이 있는지 확인한 다음 릴리스합니다.

그런 다음 필요에 따라 릴리스 분기에서 유지 관리를 수행 할 수 있으며 이러한 수정 사항은 트렁크로 쉽게 다시 병합 할 수 있습니다.

나는 이것이 완벽한 시스템이라고 주장하지는 않지만 (아직도 약간의 구멍이 있습니다-릴리스 관리가 아직 빡빡한 프로세스라고 생각하지 않습니다), 그것은 잘 작동합니다.

왜 아직도 이것을 언급하지 않습니까? 성공적인 Git 브랜칭 모델 .

저에게 최고의 분기 모델입니다!

프로젝트 규모가 작 으면 항상 다른 분기를 모두 사용하지 마십시오 (아마도 작은 기능의 경우 기능 분기를 건너 뛸 수 있음). 그러나 그렇지 않으면 그것을하는 방법입니다!

분기의 개발 코드, 트렁크에 태그가 지정된 라이브 코드.

"완벽한 코드 만 커밋"규칙이 필요하지 않습니다. 개발자가 놓친 부분은 코드 검토, 분기 테스트, 회귀 테스트, 최종 QA 테스트 등 네 곳에서 선택해야합니다.

보다 자세한 단계별 설명은 다음과 같습니다.

1. 지사에서 모든 개발을 수행하고 정기적으로 노력하십시오.
2. 독립 코드 모든 개발이 완료되면 변경 사항을 검토합니다.
3. 그런 다음 지점을 테스트로 전달하십시오.
4. 지점 테스트가 완료되면 코드를 Release Candidate 지점으로 병합하십시오.
5. 릴리스 후보 분기는 각 개별 병합 후 회귀 테스트를 거칩니다.
6. 모든 개발 지점이 병합 된 후 RC에서 최종 QA 및 UA 테스트를 수행했습니다.
7. QA 및 UAT가 전달되면 릴리스 분기를 MAIN / TRUNK 분기로 병합하십시오.
8. 마지막으로 해당 시점에서 트렁크에 태그를 지정하고 해당 태그를 Live에 배포하십시오.

dev는 트렁크에 들어가고 (svn 스타일) 릴리스 (생산 코드)는 자체 분기를 얻습니다.

"목적 별 모델"입니다 ( 분기 모델의 중요성 에 대한 그림 3 /! \ pdf).

우리는 프로덕션 코드 (주 트렁크)를 개발 코드 (모든 개발자가 자신의 지사가있는)에서 완전히 분리하여이 문제를 해결합니다.

QA 및 코드 검토자가 철저하게 검사하기 전에 프로덕션 코드에 코드를 사용할 수 없습니다.

이런 식으로 어떤 코드가 작동하는지 혼동하지 않고 항상 주요 지점입니다.

아, 그렇습니다-다른 하나-우리는 cvs HEAD에 비 프로덕션 코드 (예 : 도구 스크립트, 테스트 유틸리티)가 유지되지 않습니다. 일반적으로 "우연히"릴리스하지 않도록 명확하게 표시해야합니다.

우리는 트렁크에서 개발하고 2 주마다 분기하여 생산에 투입합니다. 중요한 버그만 지점에서 수정되며 나머지는 2 주 더 기다릴 수 있습니다.

트렁크의 유일한 규칙은 커밋이 아무 것도 깨지 않아야한다는 것입니다. wip 코드와 테스트되지 않은 코드를 관리하기 위해 우리는 쉽게 켜고 끌 수 있도록 적절한 경우 통계를 추가합니다.

기본적으로 언제든지 트렁크를 분기하여 생산할 수 있습니다.

나는 자식을 사용하고 두 가지가 있습니다 : master 와 maint

• 마스터-개발 코드
• maint-생산 코드

코드를 프로덕션에 릴리스하면 태그를 지정하고 마스터 를 maint 브랜치에 병합 합니다. 나는 항상 maint 지점 에서 배포 합니다. 개발 브랜치의 패치 나는 maint 브랜치로 패치를 선택하고 패치를 배포합니다.

현재 프로덕션에 있거나 곧 배포 될 "릴리스"지점이 있습니다 (이미 대부분의 QA를 통과 함)

각 프로젝트 또는 경우에 따라 다른 프로젝트에는 릴리스에서 분기 된 자체 분기가 있습니다.

변경 사항은 프로젝트 개발자가 자신의 프로젝트 자체 지점으로 커밋합니다. 주기적으로 릴리스는 개발 지점으로 다시 병합됩니다.

지점의 작업 패키지가 모두 QA (단위 테스트, 시스템 테스트, 코드 검토, QA 검토 등)되면 지점이 릴리스 지점으로 병합됩니다. 새 빌드는 릴리스 브랜치에서 빌드되며 해당 버전에서 최종 유효성 검사가 수행됩니다.

병합이 완료된 후 문제가 발견 될 때까지 프로세스는 기본적으로 정상입니다. WP가 병합 된 후 "고정"되면, 수정 될 때까지 고정 된 후에 모든 것을 유지합니다 (고착 된 릴리스가 릴리스 될 때까지 다른 릴리스를 수행 할 수 없음).

또한 매우 유연합니다. 매우 짧은 시간 단위 (1 ~ 2 일 정도)로 릴리스 된 경우 릴리스 브랜치에서 매우 사소한 변경이 발생할 수 있습니다.

어떤 이유로 변경 사항이 프로덕션에 직접 적용된 경우 (수정하기 위해 즉각적인 코드 변경이 필요한 중요한 고객 영향 프로덕션 문제) BRANCH_RELEASE로 다시 변경됩니다. 거의 일어나지 않습니다.

프로젝트에 따라 다릅니다. 우리의 웹 코드는 꽤 일관성있게 체크인되는 반면, 애플리케이션 코드는 컴파일 된 경우에만 체크인됩니다. 나는 이것이 우리가 물건을 출시하는 방법과 매우 유사하다는 것을 알았습니다. 응용 프로그램이 최종 기한에 도달하는 동안 웹은 가능할 때마다 올라갑니다. 그래도 두 방법 모두에서 품질 손실을 보지 못했습니다.