지속적인 통합을 수행 할 때 최고의 분기 전략?

지속적인 통합을 수행 할 때 최고의 분기 전략?

---

지속적인 통합을 원할 때 가장 좋은 분기 전략은 무엇입니까?

1. 릴리스 분기 : 트렁크에서 개발하고 각 릴리스에 대해 분기를 유지합니다.
2. 기능 분기 : 각 기능을 별도의 분기에서 개발하고 안정된 경우에만 병합합니다.

이 두 가지 전략을 함께 사용하는 것이 합리적입니까? 에서와 같이 각 릴리스에 대해 분기하지만 큰 기능에 대해서도 분기합니까? 이러한 전략 중 하나가 지속적인 통합과 더 잘 맞을까요? 불안정한 트렁크를 사용할 때 지속적인 통합을 사용하는 것이 합리적일까요?

---

나는 일상 업무에서 지사에 크게 의존하기 때문에 주제가 정말 흥미로워 요.

• Mark Shuttleworth가 기존 CI를 넘어서면서 메인 브랜치를 깨끗하게 유지하는 모델을 제안한 것을 기억합니다. 여기 에 그것에 대해 게시했습니다 .
• Cruise Control에 익숙하기 때문에 여기에서 작업 분기 및 CI에 대한 블로그도 게시 했습니다 . Plastic SCM 으로 수행하는 방법을 설명하는 단계별 자습서 입니다.
• 마지막으로, CI에 관한 Duvall의 책에서 CI에 대한 일부 주제 (그리고 잠재적으로 분기에 대해 이야기 할 수 있음) 도 매우 흥미로 웠습니다 .

흥미로운 링크를 찾으시기 바랍니다.

---

대답은 팀의 규모와 소스 제어의 품질, 복잡한 변경 세트를 올바르게 병합하는 능력에 따라 다릅니다. 예를 들어 CVS 또는 SVN과 같은 전체 분기 소스 제어에서는 병합이 어려울 수 있으며 첫 번째 모델을 사용하는 것이 더 나을 수 있지만 IBM ClearCase와 같은 더 복잡한 시스템을 사용하고 팀 규모가 더 큰 경우 두 번째 모델이 더 나을 수 있습니다. 모델 또는 둘의 조합.

저는 개인적으로 각 주요 기능이 개별 개발자가 수행 한 각 변경 사항에 대한 작업 하위 분기와 함께 별도의 분기에서 개발되는 기능 분기 모델을 분리합니다. 기능이 안정화되면 트렁크에 병합되어 합리적으로 안정적으로 유지되고 항상 모든 회귀 테스트를 통과합니다. 릴리스주기가 끝날 무렵에 모든 기능 분기가 병합되면 안정성 버그 수정 및 필요한 백 포트만 수행하는 릴리스 시스템 분기를 안정화하고 분기하는 반면 트렁크는 다음 릴리스의 개발과 다시 사용됩니다. 새로운 기능 분기를 위해 분기합니다. 등등.

이러한 방식으로 트렁크에는 항상 최신 코드가 포함되지만,이를 합리적으로 안정적으로 유지하여 주요 변경 및 기능 병합에 대해 안정적인 레이블 (태그)을 생성 할 수 있습니다. 기능 분기는 지속적인 통합을 통해 빠르게 진행되는 개발이며 개별 작업 하위 분기가 자주 발생할 수 있습니다. 기능 브랜치에서 새로 고침을 통해 모든 사람이 동일한 기능에 대해 동기화 상태를 유지하면서 동시에 다른 기능을 작업하는 다른 팀에 영향을주지 않습니다.

동시에 역사를 통틀어 일련의 릴리스 브랜치가 있으며, 여기서는 어떤 이유로 든 제품의 이전 버전 또는 최신 릴리스 버전을 유지하는 고객에게 백 포트, 지원 및 버그 수정을 제공 할 수 있습니다. 트렁크와 마찬가지로 릴리스 분기에서 지속적인 통합을 설정하지 않고 모든 회귀 테스트 및 기타 릴리스 품질 관리를 통과 할 때 신중하게 통합됩니다.

어떤 이유로 두 기능이 상호 의존적이며 서로 변경해야하는 경우 동일한 기능 브랜치에서 둘 다 개발하거나 기능이 코드의 안정적인 부분을 트렁크에 정기적으로 병합 한 다음 변경 사항을 새로 고치는 것을 고려할 수 있습니다. 트렁크 분기간에 코드를 교환하기위한 트렁크. 또는 이러한 두 기능을 다른 기능과 분리해야하는 경우 해당 기능 분기를 분기하고 기능간에 코드를 교환하는 데 사용할 수있는 공통 분기를 만들 수 있습니다.

위의 모델은 50 명 미만의 개발자와 부족한 분기 및 CVS 또는 SVN과 같은 적절한 병합 기능이없는 소스 제어 시스템에서는별로 의미가 없습니다. 이로 인해 전체 모델을 설정, 관리 및 통합하는 데 악몽이 될 것입니다.

---

저는 개인적으로 안정적인 트렁크를 갖고 기능 분기를 수행하는 것이 훨씬 더 깔끔하다는 것을 알았습니다. 이렇게하면 테스터 등이 단일 "버전"을 유지하고 트렁크에서 업데이트하여 코드가 완성 된 모든 기능을 테스트 할 수 있습니다.

또한 여러 개발자가 서로 다른 기능에 대해 작업하는 경우 모두 고유 한 분기를 보유한 다음 완료되면 트렁크에 병합하고 테스터가 여러 가지 기능을 테스트하기 위해 여러 분기로 전환하지 않고도 테스트 할 기능을 보낼 수 있습니다.

추가 보너스로 자동으로 제공되는 통합 테스트 수준이 있습니다.

---

각 개발자가 매일 트렁크 / 메인 라인에 투입하는 핵심 원칙 중 하나를 기억한다면 두 전략 모두 지속적인 개발과 함께 사용할 수 있다고 생각합니다.

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay

편집하다

나는 CI에 대한 이 책 을 읽고 있었고 저자들은 릴리스별로 분기하는 것이 선호하는 분기 전략이라고 제안합니다. 동의해야합니다. CI를 사용할 때 기능별로 분기하는 것은 의미가 없습니다.

내가 왜 이런 식으로 생각하는지 설명하려고 노력할 것입니다. 세 명의 개발자가 각각 한 가지 기능을 사용하여 작업한다고 가정합니다. 각 기능은 완료하는 데 며칠 또는 몇 주가 걸립니다. 팀이 지속적으로 통합되도록하려면 최소한 하루에 한 번 메인 브랜치에 전념해야합니다. 이 작업을 시작하자마자 기능 브랜치를 만드는 이점을 잃게됩니다. 그들의 변경 사항은 더 이상 다른 모든 개발자의 변경 사항과 분리되지 않습니다. 그렇기 때문에 애초에 기능 브랜치를 생성해야하는 이유는 무엇입니까?

릴리스 별 분기를 사용하면 분기 간의 병합이 훨씬 적고 (항상 좋은 일입니다) 모든 변경 사항이 최대한 빨리 통합되고 (올바르게 수행 된 경우) 항상 릴리스 준비가 된 코드 기반을 보장합니다. 릴리스 별 분기의 단점은 변경 사항에 대해 훨씬 더주의해야한다는 것입니다. 예를 들어 대규모 리팩토링은 점진적으로 수행되어야하며 다음 릴리스에서 원하지 않는 새 기능을 이미 통합 한 경우에는 일종의 기능 전환 메커니즘을 사용하여 숨겨야합니다 .

다른 편집

이 주제에 대해 하나 이상의 의견이 있습니다. 다음은 CI로 분기되는 프로 기능인 블로그 게시물입니다.

http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/

---

릴리스 브랜치는 매우 유용하며 앱의 여러 버전을 유지해야하는 경우 절대적으로 필요합니다.

기능 브랜치는 매우 편리합니다. 특히 한 개발자가 큰 변경 작업을해야하고 다른 개발자는 여전히 새 버전을 출시해야하는 경우에 그렇습니다.

그래서 두 가지 메커니즘을 모두 사용하는 것은 매우 좋은 전략입니다.

Book of SVN 에서 흥미로운 링크 .

---

저는 최근에 git 을 사용할 때이 모델 을 좋아하게되었습니다 . 질문에 "svn"태그가 지정되어 있어도 여전히 사용할 수 있습니다.

지속적인 통합은이 모델의 "develop"브랜치 (또는 당신이 부르는 무엇이든)에서 어느 정도 일어날 수 있지만, 향후 릴리스를 위해 기능 브랜치를 오래 실행한다고해서 어딘가에서 코드에 발생하는 모든 변경 사항을 고려할만큼 엄격하지 않을 것입니다. 당신이 정말로 그것을 원하는지에 대한 질문은 남아 있습니다. Martin Fowler는 그렇습니다.

---

지속적인 통합은 분기 전략을 결정하는 요소가되어서는 안됩니다. 분기 접근 방식은 팀, 개발중인 시스템 및 사용 가능한 도구를 기반으로 선택해야합니다.

라고 한 ...

• 설명하는 두 가지 접근 방식 모두에서 CI를 사용할 수없는 이유가 없습니다.
• 이러한 접근 방식은 잘 조합되어
• 두 가지 모두 다른 것보다 "더 잘"작동하지 않습니다.
• CI는 불안정한 트렁크로 총체적으로 이해됩니다.

All of this was answered in the fourth question on the page that you took the diagrams from: http://blogs.collab.net/subversion/2007/11/branching-strat/

---

As long as you understand principles, you can always re-invent the best practices. If you don't understand principles, the best practices will take you that far before falling apart due to some conflicting external requirement.

For best intro into the Mainline Model, read this: https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Read the link. Once you got the basics, read the following article by venerable Henrik Kniberg. It will help you relate Mainline Model with continuous integration.

http://www.infoq.com/articles/agile-version-control

---

When we started our team we inherited a release-based strategy from the vendor that originally developed the system we were about to get in charge of. It worked up until the time when our customers requested that several developed features should not be included in a release (f.y.i. ~250k lines of code, ~2500 files, Scrum with XP SDLC).

Then we started looking at feature-based branches. This also worked for a while - like 2 months until the point we realized that our regression testing process would take over 2 weeks which combined with the uncertainty of what would be released created a huge inconvenience.

The final "nail in the coffin" of pure SC strategies came when we decided that we should have 1. stable trunk and 2. Production should contain ST, UAT, and Regression tested BINARIES (not just source - think CC.)

This lead us to devise a strategy that is a hybrid between feature and release-based SC strategies.

So we have a trunk. Every sprint we branch out the sprint branch (for the non-agile folks - a sprint is just a time-boxed development effort with variable output based on complexity.) From the sprint branch we create the feature branches and parallel development starts in them. Once features are complete and system tested, and we receive intent to deploy them, they are merged to the sprint branch - some may float across several sprints, usually the more complex ones. Once the sprint is near its end and the features are complete ... we "rename" the sprint branch to "regression" (this allows CruiseControl to pick it up without any reconfiguration) and then regression/integration testing begins on the cc-built EAR. When that is all done, it goes in production.

In short, feature-based branches are used to develop, system test and UAT functionality. The sprint branch (really the release branch) is used to selectively merge features on-demand and integration-test.

Now here is a question to the community - we are obviously having trouble performing continuous integration because of the fact that development happens on many branches and the reconfiguration overhead of CruiseControl. Can someone suggest and advice?

---

The way I see it you want to have a limited set of branches where you can focus. Since you want tests, code quality metrics, and many interesting things to run with the builds, having too many reports will probably get you to miss info.

When and what to branch, usually depends on the size of the team and the size of the features being developed. I don't think there is a golden rule. Make sure you use an strategy where you can get feedback early/often, and that includes having quality involved from the very beginning of the features. The quality bit, means that as you are automating as the team develops, if you branch for a large feature set a team is building, you gotta have quality involved in the team as well.

ps Where did you get those approach references? - doesn't feel that those graphs represent all the options

Update 1: Expanding on why I said it isn't a golden rule. Basically for relatively small teams I have found it best using an approach that is a mix. Feature branches are created if it is something long and part of the team will continue adding smaller features.

---

Dave Farley, an author of Continuous Delivery, referred to Trunk Based Development (TBD) as the cornerstone of Continuous Integration (CI) and Continuous Delivery (CD). He says:

Any form of branching is antithetical to Continuous Integration.

He also says,

Feature Branching is very nice from the perspective of an individual developer but sub-optimal from the perspective of a team. We would all like to be able to ignore what everyone else is doing and get on with our work. Unfortunately, code isn’t like that. Even in very well-factored code-bases with beautiful separation-of-concerns and wonderfully loosely-coupled components, some changes affect other parts of the system.

Trunk Based Development (TBD) is the practice of integrating code changes into the trunk (a.k.a, master, mainline) at least once per day - preferably multiple times per day. Continuous Integration (CI) is a similar practice except that it also involves verifying the code changes using automated tests. The best branching strategy for this is to work directly off the trunk and to perform code reviews through Pair-Programming. If for some reason you can't pair, or you just really want to branch, make sure your branches are short-lived (less than a day).

I work on Trunk, “master” in my GIT repos. I commit to master locally and push immediately, when I am networked, to my central master repo where CI runs. That’s it!

For large features (i.e. ones that take longer than a day), try to break them into small chunks of logic which can be integrated into the trunk without breaking the software. You can also use techniques such as feature-flagging and branching by abstraction which allow you to deploy incomplete work without affecting end users.

I use branch by abstraction, dark-releasing and sometimes feature-flags. What I get in return is fast, definitive (at least to the quality of my testing) feedback.

---

I think the tools you use are a big factor here.

• If you are using subversion, sticking with option 1 and release from branches.
• If you are using GIT, option 2 will work well for you.

참고URL : https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration