기업에서는 왜 gitlab을 사용하나요? 워크플로는 어떤 모습인가요?

기업에서는 왜 github, gitee 대신 gitlab을 사용하나요? 다음 글에서는 그 이유를 소개하고 Gitlab 워크플로에 대해 이야기하겠습니다. 모든 사람에게 도움이 되기를 바랍니다.

정식 용어:

GitLab은 GitLabInc.에서 networkGit 기반의 MIT 라이센스를 사용하여 개발했습니다. 창고 관리 도구, 그리고 wiki 및 문제 추적 기능. Git을 코드 관리 도구로 활용하고, 이를 기반으로 웹 서비스를 구축해 보세요.

GitLab은 우크라이나 프로그래머 Dmitriy Zaporozhets와 Valery Sizov가 개발했으며 Ruby 언어로 작성되었습니다. 나중에 일부 부분이 Go 언어로 다시 작성되었습니다. 2018년 5월 현재 회사에는 약 290명의 팀원과 2,000명 이상의 오픈 소스 기여자가 있습니다. GitLab은 IBM, Sony, Jülich Research Center, NASA, Alibaba, Invincea, O'Reilly Media, Leibniz-Rechenzentrum(LRZ), CERN, SpaceX 등과 같은 조직에서 사용됩니다.

GitLab에는 소스 코드 탐색, 결함 및 댓글 관리 기능 등 Github과 유사한 기능이 있습니다. 저장소에 대한 팀 액세스를 관리하고, 커밋된 버전을 쉽게 찾아볼 수 있으며, 파일 기록 라이브러리를 제공합니다. 내장된 간편 채팅 프로그램(Wall)을 이용하여 팀원들이 소통할 수 있습니다. 또한, 코드를 쉽게 재사용할 수 있도록 코드 조각 수집 기능도 제공합니다.

Why

회사에서는 왜 github, gitee 대신 gitlab을 사용하나요?

프로젝트의 버전이 많아지고 개발자가 많아지면 단순한 Git 관리는 여전히 문제가 많습니다. 개발자의 권한이 너무 많고, 운영 및 유지 관리 담당자가 아는 바가 많지 않기 때문입니다. 개발 프로세스에 대해 더 나은 도구를 사용하여 프로젝트를 관리하려고 합니다. 그래서 gitlab을 생각하게 됐어요.

CI/CD

CI/CD는 실제로 CI(지속적 통합), 지속적 전달 및 CD(지속적 배포)를 의미하며 소프트웨어 엔지니어는 업데이트된 코드의 복사본을 매일 공유 위치에 자주 전달합니다. 프로세스. 모든 개발 작업은 예정된 시간이나 이벤트에 통합된 후 테스트 및 빌드 작업이 자동화됩니다. CI를 통해 개발 과정에서 발생하는 오류를 적시에 발견할 수 있어 전체 개발 주기가 빨라질 뿐만 아니라 소프트웨어 엔지니어의 업무 효율도 향상됩니다. 그리고 CD는 고품질 애플리케이션을 만드는 퍼즐의 두 번째 조각인 CD(Continuous Delivery)를 의미합니다. CD는 기술과 도구를 사용하여 생산 단계 코드를 신속하게 제공하는 소프트웨어 개발 분야입니다. 대부분의 배송 주기가 자동화되어 있으므로 이러한 배송을 신속하게 완료할 수 있습니다.

CI/CD 워크플로는 나중에 자세히 소개하겠습니다

권한 제어 및 협업

GitLab 프로젝트에서 함께 작업하는 가장 쉬운 방법은 공동 작업자에게 Git 저장소에 대한 직접 푸시 권한을 부여하는 것입니다. 프로젝트 설정의 "구성원" 섹션을 통해 프로젝트에 작성자를 추가하고 새 공동작업자를 액세스 수준과 연결할 수 있습니다. 공동작업자에게 "개발자" 이상의 액세스 수준을 부여하면 이 사용자는 저장소에 직접 커밋할 수 있습니다. 또는 제한 없이 지점을 운영할 수 있습니다.

협업을 더욱 분리시키는 또 다른 방법은 병합 요청을 사용하는 것입니다. 장점은 프로젝트를 볼 수 있는 모든 공동 작업자가 통제된 방식으로 프로젝트에 기여할 수 있다는 것입니다. 직접 액세스 권한이 있는 공동 작업자는 간단히 브랜치를 생성하거나, 이 브랜치를 커밋하거나, 마스터 또는 다른 브랜치에 대한 병합 요청을 열 수 있습니다. 저장소에 대한 푸시 권한이 없는 공동 작업자는 저장소를 "포크"하고 해당 복사본을 커밋한 다음 해당 복사본에서 기본 프로젝트로 병합 요청을 열 수 있습니다. 이 모델을 사용하면 프로젝트 소유자는 저장소에 어떤 커밋이 이루어지고 언제 알 수 없는 협력자의 기여가 허용되는지에 대한 완전한 제어권을 갖게 됩니다. (github과 다소 유사하지만 현재 github 비공개 라이브러리는 유료입니다.)

GitLab에서 요청과 이슈를 병합하는 것은 오랜 논의의 주요 부분입니다. 각 병합 요청을 통해 변경 사항이 제안된 줄(간략한 코드 검토 가능)과 전체 주제에 대한 토론이 가능합니다. 둘 다 사용자에게 할당하거나 마일스톤 인터페이스로 구성할 수 있습니다.

이 섹션에서는 주로 GitLab의 Git 관련 기능에 중점을 두지만 성숙한 시스템인 GitLab은 프로젝트 위키, 시스템 유지 관리 도구 등 공동 작업에 도움이 되는 다양한 제품을 제공합니다. GitLab의 좋은 점 중 하나는 일단 서버가 실행되면 구성 파일이나 SSH를 서버에 조정할 필요가 거의 없다는 것입니다. 대부분의 관리와 일상적인 사용은 브라우저 인터페이스에서 수행될 수 있습니다.

Git Flow 워크플로 소개

일반적으로 기업의 프로젝트는 여러 사람이 동시에 개발하므로 Git 브랜치를 어떻게 관리할지가 중요한 문제가 되었습니다.

여기서는 git flow 워크플로를 소개해야 합니다.

코드 실행 환경부터 시작해 보겠습니다. 일반적으로 코드가 실행되는 환경은 회사 팀이 다음 환경 중 하나 이상을 보유한다는 것입니다.

• 로컬 개발 환경: 개발자 테스트의 경우 로컬로 배포된 정적 서버일 수 있습니다. npm 서버를 실행하는 것과 유사한 환경과 유사할 수 있습니다. 로컬 환경에서 실행되는 코드는 모든 브랜치일 수 있습니다.
• dev 개발 환경: 이 환경은 개발 브랜치 dev에서 생성된 코드를 사용하여 배포되며 유일한 공개 환경입니다.
• 테스트 및 사전 릴리스 환경: 이 환경은 개발 브랜치 릴리스에서 생성된 코드를 사용하여 배포됩니다. 유일한 공개
• 온라인 프로덕션 환경: 이 환경은 개발 브랜치 마스터를 사용하여 생성됩니다.

해당 git 브랜치 모델은

해당 브랜치 전략은

• master: 보호 브랜치, ⽣ 프로덕션 환경 브랜치
• release: 보호 브랜치, all 개발된 브랜치는 릴리스 브랜치에 병합되어 테스트를 위해 테스터에게 제공됩니다.
• feature-*: 기능 브랜치, 특정 기능 개발
• dev/ test-*: 개발 브랜치 & 더티 브랜치, 모두가 공유하는 개발 환경에 해당 . 위 코드는 개발자가 자체 테스트를 수행하고 일상적인 작업을 처리할 수 있도록 공개 개발 환경에 배포됩니다. , 일일 디버깅
• hotfix-*: 마스터에 직접 병합할 수 있는 버그 응급 복구 브랜치( 릴리스가 여러 기능 브랜치를 병합하는 경우 테스트 중에 긴급 복구가 필요한 버퍼가 발견되면 긴급 복구 테스트가 완료된 후 릴리스로 병합된 다음 릴리스에서 직접 병합할 수 있습니다. 마스터님, 테스트 중인 기능이나 아직 출시 준비가 되지 않은 기능은 바로 실행됩니다)

워크플로우 소개

• 요구사항 문서를 받아 검토하고 각 개인 또는 그룹에 할당 기능을 개발하려면 관련 담당자가 마스터에게 기능 포인트를 확인하게 됩니다

• 개발 중에 로컬에서 테스트하는 것 외에도, 필요하다면 dev 브랜치에 병합하여 공용 개발 환경에서 테스트하기 때문입니다

• 기능 개발 중 핫픽스가 마스터에 병합될 수 있습니다. 코드 병합 시 ⽌충돌 등을 방지하기 위해 마스터에 병합하는 것이 관례입니다.

• ⾃테스트가 완료된 후 릴리스에 병합을 신청하세요. 병합이 성공하면 테스트 환경에 배포하고 테스터에게 테스트를 하라고 알립니다

• 테스트가 통과되면 릴리스 애플리케이션이 마스터에 병합되어 온라인으로 전환될 준비가 됩니다

• 테스트가 실패하면, 함수 브랜치가 수정된 후 다시 병합

• 해당 함수 브랜치가 온라인에서 성공적이고 안정된 후 삭제하고 개발자가 최신 마스터 브랜치를 병합합니다

(학습 영상 공유: 기본 프로그래밍 영상 )

위 내용은 기업에서는 왜 gitlab을 사용하나요? 워크플로는 어떤 모습인가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!