생산 지사가 있거나 마스터를 사용합니까?

16

Rails응용 프로그램 에서 다른 원격 개발자와 함께 소규모 팀에서 일하고 있습니다. git워크 플로우 수정을 시작했습니다 . 우리는 다음과 같은 분기 구조에 대해 생각했습니다.

(dev) -> (qa) -> (stag) -> (master)

그러나 일부 개발자는 마스터에서 자동으로 프로덕션 환경으로 전환 할 수있는 새로운 개발자에게는 혼동을 줄이겠다 고 생각했습니다. 그들은 모두가 마스터 작업을하고 생산을위한 별도의 지점을 만들도록 생각했습니다.

(master) -> (qa) -> (stag) -> (prod)

나는 당신이 마스터 배포를 유지하고 개발로 사용하지 않기를 원한다고 배웠으며, 내가 일했던 이전의 장소에서 항상 프로덕션을 위해 배포 할 수 있어야합니다.

마스터가 개발에 적극적으로 사용되고 분기 별 분기가 배포에 사용되는 분기 구조를 사용하면 어떤 단점이 있습니까?

git

내 경험상, "항상 컴파일"에 대한 요구 사항없이 사람들이 의지에 의존 할 수있는 장소 (매일 체크인 또는 기타)를 지불하는 것이 좋습니다. 그렇지 않으면 사람들이 체크인을 지연시키고 사고로 코드가 손실 될 위험이 있습니다 (예 : 디스크 충돌). 그런 다음 거기에서 의미있는 버전을 전파하고 통합 스트림으로 "릴리스"하는 것은 그들에게 달려 있습니다. 그래서 내가 선호하는 단계 세트는 (dev)-> (units)-> (integration)-> (test)-> (production)

— BitTickler

2

이 사이트에서 설명한 git 워크 플로를 몇 가지 차이점과 함께 성공적으로 사용합니다. nvie.com/posts/a-successful-git-branching-model 유일한 차이점은 깨끗한 역사를 유지하고 논리 "하나의 커밋, 하나의 문제"를 따르기 위해 로컬 브랜치 스 쿼싱 을 선호한다는 것입니다.

— Jepessen

"사슴"지점에서 일반적으로 어떤 일이 발생합니까?

— simgineer

보다 선명한 CI / CD를 권장합니다. 마스터 브랜치는 잘못 해석되어 사용되지 않습니다. {develop}-{unit}-{integration}-{staging}-{production}. 청색 / 녹색으로 생산을 지속적으로 구축> 활성 슬라이스로하고 스테이징> 비활성 슬라이스로 만듭니다. HEAD> 기능이 분기 된 분기를 개발합니다. 통합 및 스테이징에 대한 단위 진행 (통합을 전달할 때 적절한 태그 사용)으로 빌드를 트리거하는 웹 후크를 개발합니다. 개발 + 생산에 대한 핫픽스 (드물지만 발생합니다). 더 복잡한하지만 일반적인 아이디어.

— Jimmy MG Lim

16

이 방법에는 장단점이 없습니다. 내가 이것이 말하는 이유는 간단합니다. Git에게 마스터에서 개발하거나 마스터에서 릴리스하더라도 아무런 차이가 없습니다. 분기를 해제 할 필요도 없습니다. 임의의 커밋에 태그를 지정하고 대신 해제 할 수 있습니다.

여기서 진짜 문제는 프로세스와 절차 중 하나입니다. 한 가지 방법으로 수행하는 것을 우려하는 상급 개발자들은 혼란을 겪을 것이므로 새로운 개발자는 출시 모델이 무엇인지, 왜 그런지 설명하는 데 시간을 투자해야합니다.

너무 오래로 모두가 마스터가 개발하고, 다른 임의의 지점이 릴리스하다는 것을 이해 하고이를 유지하는 작업이 완료 ,이 접근 방식에 문제가 없을 것이다.

— 마코토
소스

1

나는 당신이 좋은 지적을했다고 생각합니다. 피드백을 주셔서 감사합니다.

커밋 태그 지정에 +1 나는 대부분 혼자서 일하지만 두 가지 이유로 릴리스에 태그를 지정합니다. 1) 시각적 커밋 히스토리 도구와 함께 작동하여 실제로 커밋 된 커밋을 보여줍니다. 2) 태그가 지정된 커밋을 확인하고 소비를 위해 zip 파일로 패킹하여 릴리스 버전을 패키지 할 수있는 GitHub와 같은 도구와 함께 작동합니다.

— nbering April

9

당신의 딜레마를 볼 수 있습니다. 내가 항상 주인에 대해 생각했던 것을 배우지 않을 때까지 나는 그것을 가지고 있었다.

나는 당신이 마스터 배포를 유지하고 개발로 사용하지 않기를 원한다고 배웠으며, 내가 일했던 이전의 장소에서 항상 프로덕션을 위해 배포 할 수 있어야합니다.

Git의 문서 / 책에서 -Git 분기

Git의“마스터”브랜치는 특별한 브랜치가 아닙니다. 다른 지점과 똑같습니다. 거의 모든 리포지토리에 하나만있는 이유는 git init 명령이 기본적으로 생성하고 대부분의 사람들이 변경하지 않아도되기 때문입니다.

당신이 선호하는 워크 플로우를 가지고 있고, 팀에 다른 개발자에 대한 다른 생각을 가지고 있기 때문에 그래서, 그것으로 작업하기가 어렵습니다 master. 아래처럼 워크 플로 master를 말하고 prod사용하도록 이름 을 바꿀 수도 있습니다.

(dev) -> (qa) -> (stag) -> (prod)

마스터 브랜치 이름 을 변경하는 방법은 다음과 같습니다 .

master지점 이름을 변경해야한다는 말은 아닙니다 . 그러나 선호하는 워크 플로우가 있고 master지사 이름 을 변경하는 데 도움이된다면 반드시 수행하십시오 :-)

— 수메 파릭
소스

아주 좋은 지적입니다. 그걸 깨워 줘서 고마워 우리가 이름을 바꿀 때까지 갈지는 모르겠지만 git이 마스터를 특별한 방식으로 취급하지 않는다는 것을 아는 것이 좋습니다. 감사!

6

이 경우 규칙을 확인하는 것을 선호합니다. 모든 팀에는 새로운 기능을 시작하는 데 더 능숙한 멤버와 릴리스를 위해 물건을 안정화시키는 데 더 나은 멤버가 있습니다.

후자가 없다면 코드 검토가 도움이 될 것입니다 (종종 더 훈련 된 사람들은 어쨌든 코드 검토를 원할 것입니다).

그렇기 때문에 특정 사용자 만 풀 요청을 병합 할 수 있고 각 개발자가 자체 리포지토리의 개인 포크를 받도록 Git 리포지토리 (Gitlab을 사용하고 있음)를 구성하는 이유입니다.

두 가지 문제가 해결됩니다.

새로운 개발자는 잘못된 브랜치를 변경할 수 없습니다 (작업을 직접 메인 리포지토리로 푸시 할 수 없기 때문에). 그들은 master자신의 리포지토리로 푸시 할 수 있지만 풀 요청이 들어올 때 수정됩니다.
각 커밋은 자신의 견해와 지식을 가져 오는 다른 사람이 확인하기 때문에 코드 규칙이 팀을 통해 빠르게 전파됩니다.

— 아론 디 굴가
소스

1

그것은 모든 소프트웨어 개발 프로세스에 달려 있습니다. 전체 프로세스를 모르면 구성 관리 및 새 버전을 정의하는 방법을 정의 할 수 없습니다.

"항상 첫 번째 커밋 영역에서 작업"을 선택하는 "민첩한"팀이 있습니다. 그들은 해당 지역에 대해 지속적으로 자동화 된 빌드 및 테스트 시설을 운영하고 "항상"작동 시스템을 갖추려고 노력했습니다.

그들은 아마도 1,2 개의 중간 단계 구성이있는 (마스터)-> (릴리스)를 유리하게 볼 것입니다.

그런 다음, "작업 단위"릴리스는 "(단위) 테스트 할 때만 릴리스"와 같은 요구 사항이있는 계획된 활동 인 계획 및 계획된 통합 단계를 통해 마일스톤을 향한 프로세스를 갖는 "클래식"파벌이 있습니다. 다음 계획된 이정표에 맞아야합니다. " 여기에서 계획은 "작업 단위"의 버전 화로 구성되며 일반적으로 다음 계획된 제품 릴리스가 기능 및 수정 측면에서 어떻게 보일지 정의하기 위해 많은 시간을 투자합니다. 계획을 위해 개발자가 릴리스하는 것이 "적절한"작업 단위를 수행하는 의식적인 행동임을 알고 싶어합니다.

이 고전적인 접근 방식이 완전한 제품 빌드를 사용할 수없는 시간이 더 길다는 것을 의미하지는 않습니다.

따라서 "클래식"워크 플로우는 (dev)-> (unit)-> (integration)-> (test / qa)-> (production)입니다.

통합 자의 역할은 릴리스 된 유닛을 "수락 / 구매"하거나 다음 릴리스의 요구에 맞지 않으면 거부하는 것입니다.

부가 적으로이 두 가지 기본 접근법을 적절한 방식으로 혼합 할 수도 있습니다.

내 경험 (주로 "클래식"접근 방식을 사용하는 영역에 있었음)에서 "클래식"접근 방식은 팀 내 약 4-50 명의 프로젝트에서 제대로 작동했습니다.

— 비트 티 클러
소스