2013-06-15 1 views
0

내 회사는 Jenkins를 지속적인 통합에 사용하고 있으며 CD쪽으로 이동하려고합니다. git hub를 코드 저장소로 사용하고 있습니다. 지금 우리는 기능 브랜치를 uat 환경에 병합하고 특정 기능이 승인되면 기능 브랜치가 프로덕션 브랜치에 병합됩니다. 두 가지 변경 사항을 함께 테스트하고 별도로 배포 할 수 있으므로 이는 분명 위험합니다. 이상적으로 우리는 패키지를 테스트하지 않고 재 구축하지 않고 배포 할 것이지만 이것이 가능한 방법을 보는데 어려움을 겪고 있습니다. 두 사람이 서로 다른 두 가지 기능을 수행하는 경우 첫 번째 작업이 완료되고 패키징되어 테스트가 진행되며 두 번째 작업은 첫 번째 작업없이 완료되고 패키징됩니다. 그렇다면 다른 기능의 테스트를 무효화하지 않고 패키지를 어떻게 배포 할 수 있습니까? 배치 가능한 단일 패키지로 기능을 통합하는 올바른 방법이 확실하지 않습니다.병렬로 구축 할 때 연속 공급 파이프 라인의 단일 패키지

도움을 주시면 감사하겠습니다.

또한,이 수용 테스트를 통과 할 때 그는 체크인 1 배포 할 수 있습니다 당신이 http://ptgmedia.pearsoncmg.com/images/chap5_9780321601919/elementLinks/fig5_6.jpg 내 관심사 보면되고 해당 패키지가 배포됩니다 만, 수용 무엇을 실패 테스팅을한다면? 체크인 5는 체크인 1과 동일한 문제를 포함하므로 체크인 1이 고정되거나 제거 될 때까지 프로덕션에 배포 할 수 없습니다. 제거 할 커밋이 여러 개있을 수 있고 수정 + 테스트에 시간이 오래 걸릴 수 있으므로 변경 사항을 제거하는 것은 성가시다.

답변

2

연속 배달은 연속 통합의 확장입니다. CI는 다른 모든 사람의 컨텍스트에서 변경 사항을 평가하는 데 중요합니다. (하루에 한 번 미만으로 커밋하는 경우 CI로 계산할 수 없음)

분기는 모든 변경 사항을 격리하고 CI와는 근본적으로 다릅니다. 피쳐 브랜칭과 CI는 반대입니다.

대부분의 조직에서는 테스트하기 전에 분기를 병합합니다. 이는 기능 브랜치의 값을 손상 시키지만 CI의 값은 유지합니다. 이 작업을 수행하지 않으면 CI는 설명하는 이유 때문에 실제 가치가 거의 없습니다. 현실적인 상황에서 변경 사항을 평가하지는 않습니다.

미안하지만 둘 다 가질 수는 없습니다.

+0

응답을 보내 주셔서 감사합니다. – user663470

+0

잘못된 생각으로 생각하고 있습니다. 우리가 찾는 바로는 비즈니스가 가능한 빨리 핫픽스 같은 일을하고 싶어한다는 것입니다. 그런 다음 일주일 동안 기다려야하는 다른 결함이 있습니다. 그러나 때로는 변경 사항이 확대되어 신속하게 통과해야합니다. . 내가 아는 주요 문제점은 릴리스를 시도해보고 테스트를 거치지 않은 변경 사항이있을 수 있으므로 모든 UAT를 릴리스에 넣을 수 없으며 체리 피킹으로 바뀌는 것입니다 악몽. 또한 릴리스 프로세스가 정말 간단하기를 바랍니다. – user663470

0

핫픽스주기 시간의 차이와 덜 중요한 사항에 대해 기능 토글을 살펴 보았습니까? http://martinfowler.com/bliki/FeatureToggle.html

+0

링크를 제공해 주셔서 감사합니다. 예, 필자는 기능 토글 및 추상화를 통한 분기를 알고 있습니다. 새로운 기능을 도입했다면 토글을 사용 하겠지만 현재 대부분 결함을 수정하고 있으며 대부분의 팀은 전환을 위해 구성 할 수있는 방식으로 코드를 리팩터링하는 데 어려움을 겪습니다. 또한 팀 구성원 중 일부는 피쳐 토글이 검증되어야하며 오버 헤드의 가치가 없다고 생각합니다. 변경 사항 중 일부는 테스트를 위해 며칠이 걸릴 수 있습니다. 이는 출시 파이프 라인이 차단된다는 것을 의미합니다. – user663470

0

연속 배송을 원할 경우 분기는 아니오입니다. 대부분. 릴리스는 SCM에서 태그 지정되어야하며, 릴리스에 적용된 수정이 HEAD로 다시 병합됩니다.

또한 수정 프로그램이 실제로 문제를 수정했는지 확인하기위한 자동화 된 테스트가 있어야합니다. 어떤 경우에는 어려울 수 있습니다. 이 경우 최소한해야 할 일은 수정 프로그램이 기존 동작을 손상시키지 않는지 확인하는 것입니다 (수정 의도입니다).

기능 토글이 좋기 때문에 추상으로 분기하는 것이지만 실제로는 CD를 채택한 가장 성숙하고 경험이 많은 팀에서만 채택합니다. 나는 아직 그 시점에 있지 않다고 생각합니다. 그래서 이것은 CD에 익숙해 질 때까지 범프를 극복하는 데 도움이 될 것입니다.

동시에 두 가지 기능을 배포해야한다면 TDD 원칙을 사용하여 FAILING 테스트를 먼저 작성한 다음 녹색으로 전환하는 코드를 구현해야합니다. 테스트를 확인하십시오. 구현이 완료 될 때까지 빌드가 앞으로 나아갈 수 없습니다. 기능이 완전하지 않으므로이 빌드가 생산 예정으로되어 있지 않다는 것을 분명하게 알 수 있습니다.이 테스트가 CI가 아닌, 최신 테스트 단계에있는 것이 좋습니다 ... 여러 테스트 단계가있는 경우!

관련 문제