프로젝트/코드 배포 전략

Question

컨텍스트 : 저는 전통적으로 연구 형식의 작업을 수행 한 작은 소프트웨어 회사에서 일하며 상업적 공간에서는 많은 경험이 없습니다. 우리는 이제 상업적인 세계로 나아가려고 노력 중입니다. 연구의 기원으로 인해 우리는 매우 빠른 개발주기와 적절한 버전의 프로젝트 유지 측면에서 거의 구조에 익숙하지 않습니다.

문제점 : 모든 개발자가 코드 기반에 대해 약간 다른 시각을 가지고 있기 때문에 구조가 부족하다는 것이 이제는 다소 방해가되는 것으로 입증되었습니다. 한 개발자가 발견 한 문제는 다른 개발자가 재현 할 수 없으며 다음 빌드에서 발견 된 문제가 사라질 수도 있습니다 (또는 새로운 문제가 나타날 수도 있음). 이는 모든 프로젝트를 통합하고 품질 및 성능 표준 (예 : 자신)을 충족시키는 책임이있는 사람에게는 매우 실망스런 경험을합니다.

잠재적 인 해결책 : 개인적으로 고정 된 버전 번호와 일반 릴리스를 통해 더 나은 구조를 적용해야한다고 확신합니다. 적절한 버전 관리가 우리의 많은 문제에 어떻게 도움이 될지는 자명 한 사실이지만, 물론 문제가없는 것은 아닙니다. 개발자는 릴리스를 수행하고 테스트하기 위해 추가 작업을해야하며 더 이상 최신 버전을 사용할 수 없습니다. 모두.

질문 : 출시에 필요한 프로세스와 노력을 최대한 원활하게 유지하기 위해 어떤 전략을 권장합니까? 우리는 버전 관리를 위해 git을 사용하고 있으며 빌드 시스템에는 maven을 사용하고 있으며 버그 추적 및 지속적인 통합 시스템을 실행 중이므로이 도구가 있다고 믿습니다. 적절한 릴리스 프로세스가 어떤 모양인지 잘 모르겠습니다.

Answer 1

버전 관리, Maven 및 연속 빌드 서버를 통한 원 클릭 빌드, 버그 추적 등 3 가지 버전이 있습니다. 애자 일 방법론에 끌리는 것처럼 들리므로 제품의 트렁크 버전을 항상 제공 가능한 상태로 유지해야합니다.

첫 번째 릴리스를 결정할 때 해당 릴리스의 트렁크 버전에서 분기를 만듭니다. 라벨 체계를 결정하고 지점 버전에 반드시 레이블을 지정하십시오. 예를 들어 첫 번째 릴리스는 1.0.4530 일 수 있습니다. 여기서 1은 첫 번째 버전을 의미하고 0은 첫 번째 릴리스 후보자를 의미하며 4530은 버전 컨트롤 변경 번호입니다. 이 릴리스 분기를 테스트하고 중요한 버그를 수정합니다. 잠시 후 다른 릴리스 후보를 발표하면 1.1.4807라고 말합니다. 이 프로세스를 몇 번 더 반복하면 (예를 들어) 릴리스가 충분 해지고 버전 1.3.5167이 제공됩니다.

한편 새 개발은 트렁크 버전에서만 발생하며 때때로 버그 수정 사항을 1.x 릴리즈 브랜치에서 트렁크로 다시 병합해야합니다. 나중에, 두 번째 릴리스를 위해 프로세스를 반복하기 위해 트렁크의 2.x 분기를 분할합니다. 일반적으로 트렁크에 제한된 개발과 각 지점을 초기 상태로 유지하면서 개발과 독립적 인 여러 가지 활성 분기 (트렁크 포함)가 있습니다.

개발자가 문제를 일으키고 개발자 조정 문제가 줄어들 것입니다. 그러나 이러한 문제는 거의 모두 릴리스 지점이 아닌 트렁크로 제한됩니다.

Answer 2

한 개발자가 발견 한 문제는, 다음에 사라질 수 있습니다 하나의 빌드에서 발견 문제 (또는 악화가 새로운 문제가 나타날 수 있습니다) 다른 개발자에 의해 재현하지 입니다. 따라서 은 모든 프로젝트를 통합하는 사람이고 은 품질 및 성능을 보장하기 위해 매우 실망 스럽습니다. 즉 표준이 충족되었습니다.

잠재적 인 솔루션 : 개인적으로 나는 확신 우리가 고정 된 버전 번호 및 일반 출시를 통해 더 나은 구조를 적용 할 필요가입니다.

내부적으로 조정하기 위해 자주 출시 할 필요는 없습니다. 버전 관리를 통해 그렇게 할 수 있습니다. 문제를보고 할 때 특정 git 리비전에 대해 사람들에게 이야기하게하십시오. 또한 외부 종속성/라이브러리도 조정해야합니다. 어떤 종류의 vendor branches이 도움이 될 수 있습니다.

Answer 3

일반적인 주제에 대한 서적이 있습니다. 아마존 검색은 특수 "버전 제어 (git with version control)"를 위해 3 개의 제목을 반환합니다.

코드 기반의 표준보기를 정의하면 도움이된다고 생각합니다. 테스트라고 부르세요. 테스트에 문제가있는 경우 문제가 발생합니다. 일부 개발자의 관점에서 문제가 나타나지 않는 경우 개발자가 중요한 차이점을 파악하는 것은 개발자의 몫입니다. 또한 개발자의 관점에서는 나타나지만 Test에서는 나타나지 않는 문제에 대해서도 마찬가지입니다.

한 가지 규칙은 야간에 소스에서 테스트를 다시 빌드하는 것입니다. 좀 더 격렬한 규칙은 모든 업데이트시 Test가 다시 빌드되는 것입니다.팀 규모가 작고 (5 이하) 먼 거리 또는 여러 시간대에 분산되어 있지 않은 경우 적절한 첫 번째 근사값은 도구 상자가 일부 cron 작업과 함께 설치된 서버에서 git 작업 공간 테스트를 수행하여이 작업 공간 매일 밤 업데이트되고 재건됩니다 (일반적으로).

Answer 4

"테스트 분기"를 사용하고 "안정/생산 분기"를 조금 더 존중해야하는 것처럼 들립니다.

"이 지점에서 야생 서재를하십시오"라는 개념을 판매하고 결과가 만족 스러우면이 "지루한 안정적인 생산 지점"으로 합칩니다. ... (또는 이와 비슷한 것)