기본 전략(기본): 메인 라인 특징

이 기본 전략은 대부분에서 따릅니다. Mendix 모든 프로젝트의 기본 시작점이기 때문에 프로젝트입니다. 이 접근 방식은 프로젝트가 더 커지고 이미 라이브 상태일 때 종종 계속됩니다. 이 전략에서 Main Line은 거의 모든 유형의 개발에 사용됩니다. 모든 변경 사항은 Main Line에 커밋되고 배포는 Main Line을 사용해서만 수행됩니다. 변경 사항은 하나씩 커밋되고 일반적으로 섞이며 버그 수정은 그 위에 다시 커밋됩니다. 결과적으로 변경 사항은 '패키지 딜'로만 제공될 수 있습니다. 모두 가져가거나 포기하세요.

버전이 배포되면 잘못된 배포를 수정하는 옵션은 제한됩니다. 예를 들어, 1) 이전 모델 패키지로 되돌리기, 2) 최신 커밋을 되돌리고(작업을 잃음) 새 패키지를 생성하기, 3) 개발을 계속하고 잘못된 부분을 수정하기. 지금까지 제 경험상 후자의 옵션이 가장 일반적으로 따랐습니다. 최신 커밋을 롤백하는 것은 그 자체로 위험한 옵션이며, 그 이후에는 새 모델을 테스트하고 커밋해야 합니다.

일반적으로 좋은 의미의 조언: 이 기본 전략을 가능한 한 빨리 포기하세요. 예를 들어, 안정적인 버전이 테스트 환경 중 하나에 배포되거나 늦어도 프로덕션 환경에 첫 번째 릴리스가 완료될 때입니다. 당연히 궁금해하실 겁니다. 대안은 무엇일까요? 무엇을 더 잘할 수 있을까요? 개선의 여지가 어디에 있을까요?

무엇보다도 먼저 "원칙"을 채택해야 합니다.트렁크에 쓰레기를 넣지 마세요.” 일반적으로 이는 다음을 의미합니다.

• 모든 개발은 지점에서 이루어집니다(본선에서는 절대 이루어지지 않음)
• 메인 라인은 새로운 지점의 일반적인 시작점입니다.
• 완전히 테스트된 변경 사항만 Main Line에 병합됩니다.
• Main Line에 병합한 후 모든 활성 브랜치에 대한 병합이 필요합니다. 또한 브랜치에서 개발이 계속되는 경우 소스 브랜치에 대한 병합이 필요합니다. 이는 모든 브랜치가 동기화 상태를 유지하는 데 필요합니다.

유지관리 및 프로젝트 전략

"트렁크에 쓰레기 없음" 원칙을 적용하면 전략 1로 이어집니다. 즉, 유지 관리와 프로젝트를 병행하는 전략입니다. 이 전략에서는 다음과 같은 분기를 구별할 수 있습니다.

• 본선
• 예를 들어, 지속적인 유지 관리 분기라고 합니다. 유지보수 or 평소와 같이 사업 (건축사사무소)
• 선택적으로 하이라이트 주요 변경 사항에 대한 브랜치 또는 기능 브랜치
• 또한, 소규모 프로덕션 패치에 대한 핫픽스 브랜치가 있을 수 있습니다.

이 전략을 사용하면 변경 사항은 주로 지점에서만 수행됩니다. 유지보수 하이라이트 브랜치. 테스트 환경에 대한 배포는 해당 브랜치에서 생성된 패키지에서 수행됩니다. 테스트가 성공적으로 완료되면 변경 사항이 Main Line에 병합됩니다. 그 후 모든 것을 동기화하기 위해 커밋을 모든 활성 브랜치에 다시 병합해야 합니다. 프로덕션 배포는 Main Line의 버전 관리된 패키지에서 수행되고 때로는 테스트된 핫픽스 라인에서 수행됩니다.

이 전략의 주요 활동을 시각적으로 표현한 아래 그림을 참조하세요. 시간이 왼쪽에서 오른쪽으로 흐르면서 세 개의 분기가 수평선으로 표시됩니다. 유지 관리 분기, 메인 라인, 프로젝트 분기입니다. 분기에 커밋된 각 변경 사항은 해당 라인에 원으로 표시됩니다. 두 가지 변경 시리즈가 유지 관리 분기 라인에서 수행되어 커밋되었습니다(1 및 2). 이러한 변경 사항은 처음에 해당 라인에서 직접 생성된 배포 패키지로 테스트됩니다. 모든 테스트가 완료되고 승인되면 변경 사항이 메인 라인에 병합됩니다. 그림에서 병합은 화살표로 표시됩니다. 병합 후 변경 사항이 커밋(3)된 다음 프로젝트 분기 라인(4)에 병합됩니다. 마지막으로 3번에서 커밋된 변경 사항이 유지 관리 분기 라인(5)에 다시 병합되어 모든 라인이 동기화되었는지 확인합니다.

분기 및 병합을 수행하는 방법 Mendix 곰팡이

브랜치를 사용하기 시작하려면 모든 프로젝트의 전제 조건은 Team Server를 활성화하는 것입니다. 가장 쉬운 방법은 Team Server를 사용하여 모든 프로젝트를 시작하는 것입니다. 그냥 하세요. 어쨌든 무료입니다. 또는 나중에 옵션을 사용하여 이 작업을 수행할 수 있습니다. 팀 서버에 업로드… 인간을 의료진 소개 메뉴를 선택합니다.

가지

유지 관리 라인에 대한 초기 일회성 설정을 해야 합니다. 프로젝트가 시작되고 종료됨에 따라 프로젝트에 대한 새 브랜치가 필요합니다. 이전 프로젝트 브랜치를 정리하는 것을 잊지 마세요. 또한 기능 개발이나 핫픽스를 위해 새 브랜치가 필요할 수도 있습니다. 브랜치는 메뉴 옵션을 사용하여 만들 수 있습니다. 지사 회선을 관리합니다… 인사말 의료진 소개 메뉴 항목을 선택합니다.

유지관리 또는 프로젝트를 위한 새로운 분기 라인의 경우, 선택된 출처는 일반적으로 메인 라인의 최신 버전이어야 합니다. 기능 또는 핫픽스 분기의 경우, 그것이 무엇을 위한 것인지에 따라 달라집니다. 그러한 분기는 독립적으로 존재할 수도 있고, 유지관리 또는 프로젝트의 하위 분기가 될 수도 있습니다.

어느 쪽이든 모든 지사 라인은 변경 사항과 최소한 유지 관리 및 프로젝트를 전달해야 합니다. 지사 라인은 또한 동기화 상태를 유지해야 하며, 여기서 병합이 등장합니다. 때때로 기능 지사 라인은 더 오랜 시간 동안 존재하며, 동기화 상태를 유지해야 할 수도 있습니다. 지사 라인을 동기화하지 않으면 조만간 복잡한 버전 충돌이 발생합니다.

병합

병합은 다음을 사용하여 수행됩니다. 여기에 변경 사항을 병합합니다… 에서 옵션 의료진 소개 메뉴. 세 가지 옵션이 바로 앞에 나오면 처음에는 위압감을 느낄 수 있습니다. 하지만 주의 깊게 읽어보세요(사실, 잘못된 옵션은 비활성화되므로 여기서는 잘못될 수 없습니다).

병합 창

프로젝트 또는 유지 관리 분기에서 분기 회선의 변경 사항을 메인 회선으로 병합하는 작업은 종종 다음을 사용하여 수행할 수 있습니다. 포트 고정 or 기능 브랜치 병합 옵션. 수정 사항을 포팅하다 옵션에서도 여전히 하나 또는 여러 개의 개정판을 병합하도록 선택할 수 있습니다. 포트 기능 지점 이 옵션을 사용하면 이전에 병합되지 않은 모든 개정판이 병합됩니다.

포트 고정 창

포트 기능 지점 창

분기선 중 하나가 열려 있는 모델러를 사용하면 처음 두 옵션이 없으므로 다음 옵션만 남습니다. 고급 병합 옵션입니다. 거기서 병합할 브랜치 라인과 병합에 포함될 시작 및 종료 리비전을 선택해야 합니다. 리비전 선택은 병합에 모든 것을 포함시키고 싶지 않기 때문에 매우 유용합니다.

마지막으로 모든 병합(및 기타 모든 Subversion 작업)은 Windows용 Tortoise SVN 클라이언트에서 수행할 수 있습니다. Tortoise SVN은 또한 특수 옵션을 사용하여 재통합 병합 또는 병합 백을 용이하게 합니다. 모든 버전이 다음 버전과 호환되는 것은 아니라는 점에 유의하십시오. Mendix SVN 설정. 확인 Mendix Tortoise 사용에 관심이 있다면 올바른 버전에 대한 참조 가이드를 참조하세요.

개인적으로 나는 모든 분기 및 병합을 다음과 같이 수행하고 싶습니다. Mendix 모델러. Windows 탐색기에서 볼 수 있는 아이콘에 Tortoise를 설치하여 프로젝트 폴더의 상태를 직접 볼 수 있습니다. 또한 Tortoise는 파일 뷰어를 제공하며, Mendix 서로 다른(충돌하는) Java 파일 버전을 비교할 수 있는 모델러는 어떤 경우에 매우 유용했습니다.

맺음말

지금까지 이 전략에 대한 제 경험은 어떻습니까? 잘 작동하며 변화와 버전을 제어하는 ​​데 있어 좋은 진전이라고 말해야겠습니다. 좋은 모델이며 간단하며 필요한 것을 제공합니다. 그러나 이 전략은 시간이 지남에 따라 여러 가지 과제를 안겨줍니다.

1. 기능 및 수정 사항에 대한 변경 사항은 개발 분기 라인에서 누적되어 전부 또는 아무것도 없는 패키지 거래로 이어질 수 있습니다(다음 블로그에서 자세히 설명)
2. 테스트 환경에서 배포하기 위해 프로젝트와 유지 관리 분기 라인 모두의 변경 사항을 포함하는 분기를 결합하는 것은 어렵고 때로는 불가능합니다(충돌이 많이 발생하는 경우)

결론적으로, 이러한 전략의 적용 가능성과 우리가 이를 사용해 온 시간 동안 얻은 교훈을 검토해 보겠습니다. 위의 전략은 다음과 같은 상황에서 유용합니다.

• 유지보수와 프로젝트에 대한 노력을 분리하고 싶을 때
• 별도로 개발될 여러 기능 및 수정 사항이 포함된 릴리스의 경우
• 높은 위험 대비 낮은 위험 변경 트랙

제시된 전략에 대한 최종 평가는 좋은 모델이라는 것입니다. 실제로 잘 작동하며 이해할 수 있습니다. 우리는 이 전략을 1년 이상 성공적으로 사용했지만 한계로 인해 심각한 문제에 부딪혔습니다. 이 블로그의 두 번째 부분에서 이에 대해 자세히 설명합니다.

여기에서 2 부 읽기

감사

씨앗을 심어주고 분기와 병합을 개선하는 것에 대해 생각하게 해주고, 또한 개선을 계속하도록 밀어준 Richard에게 감사드립니다. Reinout, 저의 Sogeti 동료 Edzo와 Louis, 그리고 Mendix 건설적인 의견을 준 리뷰어에게 감사드립니다. 그들이 없었다면 최종 결과는 같지 않았을 것입니다.

데이비드 드 그루트에 대하여

현재 Sogeti에서 근무 중인 David는 다음과 함께 작업했습니다. Mendix 수년간 근무했으며 인증된 고급 개발자입니다. 그는 주로 유지 관리 및 지원 컨설턴트로 다양한 네덜란드 및 국제 회사에서 일했지만 간헐적으로 프로젝트 및 신규 빌드에도 참여했습니다. David는 Oracle 및 PL/SQL 개발 분야에서 경력을 쌓았으며 인공 지능 분야에서 석사 학위를 취득했습니다.

참고자료

버전 제어 개념 Mendix 문서

Subversion을 사용한 버전 제어

• https://svnbook.red-bean.com/ 예: https://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

InfoQ 책: 트렌치에서 스크럼과 XP

• https://www.infoq.com/news/2007/06/scrum-xp-book/