빌드가 거의 항상 깨질 때 효율적으로 유지하는 방법

나는 동일한 소스 코드를 공유하고 지속적인 통합을 유지하는 중소 규모의 팀에서 일하지만 우리 모두가 동일한 지점에서 작업해야하므로 빌드는 거의 항상 중단됩니다.

우리는 또한 깨진 빌드를 완화하기 위해 최근에 도입 된 규칙을 가지고 있는데, 이는 빌드하는 동안 아무도 체크인 할 수 없다는 것을 나타냅니다.

하루 종일 모든 사람들이 체크인 할 수있는 10-15 분의 창문이 있다고 말했습니다.

그리고 팀이 성장함에 따라 체크인 기회의 창은 더욱 줄어들고 있습니다. 이로 인해 개발자는 변경 사항을 로컬에 누적해야하므로 더 큰 변경 세트가 발생하므로 변경 내용이 중단되지 않도록하기가 더욱 어려워집니다. 악순환이 보입니다.

이와 같은 환경에서 효과적인 작업을 유지하기 위해 무엇을 권할 수 있습니까? 또한 관리자가 아닌 개발자이므로 프로세스 나 다른 사람의 행동을 많이 변경할 수 없습니다.

우선이 의견은 다음과 같습니다.

... 지점을 갖는 것은 추가 복잡성을 의미하므로 추가 작업이 필요합니다 ...

전적으로 거짓입니다. 나는 종종 분기에 익숙하지 않은 사람들로부터 그것을 듣지만 여전히 잘못되었습니다.

로컬로 변경 사항을 누적하는 개발자가 많은 경우 로컬 변경 사항 이 기본 저장소의 사실상의 분기 를 구성 합니다.

그들이 마침내 밀면 이것은 사실상의 합병 입니다.

브랜치와 병합이 암시 적이라는 사실은 걱정하는 추가 복잡성을 제거하지 않으며 숨길뿐입니다. 사실이 프로세스를 명시 적으로 만들면 (복수 = 전체 팀) 프로세스 관리에 도움이 될 수 있습니다.

자, 당신은 말합니다

빌드하는 동안 아무도 체크인 할 수 없습니다.

그러나이 경우 빌드를 수정할 수 없으므로 정확하지 않을 수 있습니다.

일반적으로 로컬로 빌드하는 것이 합리적이라면 (즉, 빌드가 너무 크거나 느리지 않은 경우) 개발자는 어쨌든 추진하기 전에 그렇게해야합니다.

나는 이것이 사실이 아니라고 생각합니다. 왜냐하면 처음에는 깨진 빌드를 푸시하지 않을 것이지만이 점을 분명히하면 좋을 것입니다.

일반적으로

빌드가 거의 항상 깨질 때 효율적으로 유지하는 방법

is : 빌드 중단을 중지하십시오 .

개발자는 로컬로 변경 사항을 축적합니다 ... 악순환을 볼 수 있습니다.

참으로 사악합니다. 로컬로 변경 사항을 누적하는 것은 개발 과정에서 무언가가 심하게 썩었 음을 나타내는 큰 빨간색 플래그입니다. 그것은 버전 관리 시스템 을 갖는 모든 목적을 쓰레기로 만듭니다.

프로세스 또는 다른 사람의 행동을 바꾸지 않으려면 가장 자연스러운 해결책은 자신의 지점을 설정하고 변경 사항을 "누적"하는 데 사용하는 것입니다. 기회).

실제로, 당신과 같은 사람이 더 있다면, 공동 개발 지점 을 공동으로 구축 하여 무능한 관리 아이디어를 방해하지 않고 자유롭게 업데이트를 교환 할 수 있습니다. 분기 는 팀워크를 단순화하는 여러 가지 방법을 허용합니다.

• ^{부수적으로, 관리자가 커밋을 피하고, 코드를 로컬로 유지하고, 단어를 대담하고 평범한 "나는 무능하다"고 번역하도록 강요하는 말을 할 때마다주의해야합니다 .}

본인은 관리자가 아닌 개발자이며 프로세스 나 다른 사람의 행동을 크게 바꿀 수 없습니다.

정확성을 위해, 당신은 실제로 수 있습니다 , 이러한 영향력과 의사 소통 능력의 문제가 있고 하나는 정말 자신이 뭔가에 대한 웹 검색 (원하는대로 변경 일 전원의 위치에있을 필요는 없다 "까지 관리" 당신이 경우 '자세한 내용에 관심이 있습니다).

그러나의 오히려 성가신과 노력이 많이 소요되고 하나는 단순히 숙박을 선호 만약 내가 완벽하게 이해할 수있는 정치에 거의 참여와 함께, 코딩에 집중 - 그래서 당신이하지 않으면 원하는 (당신은 이론적으로 비록 수 ), 즉 이해할 수있다. :)

나는 당신이 환경을 바꿀 힘이 없다고 생각한다는 점에 민감하지만,이 상황은 프로그래머로서 당신의 전문성에 심각한 도전이라고 생각합니다.

외과의가 깨끗한 메스로 더러운 메스를 보관하면 어떻게됩니까? 배관공이 설치 한 파이프를 테스트하지 않으면 어떻게됩니까? 바이올리니스트가 항상 오케스트라와 조율되지 않으면 어떻게 될까요?

프로그래머가 팀워크와 공통의 예의에서 면제되어야하는 이유는 무엇입니까? 해당 팀의 구성원으로서 결과에 대한 책임을 공유합니다. 자신의 노력을 방해하는 팀을 무시하는 것은 무책임합니다.

"빌드하는 동안 아무도 체크인 할 수 없습니다"라는 규칙이 어디서 유래했는지 궁금합니다. 그렇다면 모든 사람이 빌드를 수정하는 데 중점을 두는 것이 좋습니다. 예를 들어서 빌드가 깨질 때마다 빌드를 수정하도록 도와줍니다. 그것을 직면하자, 당신은 어쨌든 다른 일을하지 않습니다. 이것이 당신을 귀찮게한다면, 나는 그런 우려를 표명하는 것이 좋습니다. 상황을 개선하기 위해 적극적으로 노력하는 사람의 목소리는 모퉁이에서 불평하는 사람보다 더 큰 영향을 미칩니다.

나는 당신이 "단지 개발자"라고 생각하는 한이 문제로 인해 겪을 것들을 바꿀 수 없다고 생각합니다.

당신이해야 할 일은 누군가가 빌드를 중단 할 때마다 저장소에서 모든 커밋을 되돌려 야하고 그 사람에게 빌드를 중단하고 중지해야한다고 알려주는 것입니다. 또한이 상황을 관리자에게 설명하고이 문제로 인해 팀의 생산성이 저하되고 있다고 알려 주어야합니다.

프로세스를 개선하기 위해 가능한 모든 조치를 취해야하며 나중에 권한을 요청하는 대신 미안하다고 말하십시오.

나는 당신과 당신의 팀이 프로세스 를 변경 해야하는 상황에 처해 있고 깨진 모델로 효율적으로 작업 할 수 없다고 생각합니다. 또한 문제를 인식했을 때 그 문제에 대해 무언가를하는 것이 귀하의 책임이라고 생각합니다. 아무도 그 문제에 대해 아무 것도하지 않을 경우, 당신은해야합니다!

나는 당신의 곤경과 관련이 있습니다. 저는 최근의 직장 프로젝트와 비슷한 상황에 직면했습니다. 우리는 종류가 될 때까지 가장 최근 빌드를 부러 개발자가 보모 / 보모 /를 모니터에 있던 "뜨거운 감자"시스템의 구현 결국 고정 및 통과 모든 우리의 검증 테스트를.

빌드 및 검증 테스트는 일반적으로 ~ 4 시간이 걸리기 때문에 성공했습니다. 따라서 빌드를 중단하면 실제 작업에서 반나절을 잃을 수 있습니다. 말할 필요도없이 개발자는 가지를 트렁크에 병합하기 전에보다 효율적으로 분기를 사용하게되었습니다. 대부분의 개발자들에게 이전의 사고 방식은 "코드가 깨졌을 때 CI 빌드 시스템이 알려주도록하겠습니다."

CI 시스템을 간단하게 변경하면됩니다. 빌드를 중단시키는 모든 변경 사항이 자동으로 롤백됩니다. 더 좋은 점은 CI 리포지토리가 준비 영역이되게하는 것입니다. 여기서는 빌드가 녹색 일 때만 변경 사항이 신뢰할 수있는 리포지토리로 전달됩니다. Gerrit와 같은 도구가 여기에서 도움을 줄 수 있습니다.

다른 두 가지가 여기에 도움이 될 수 있습니다.

• 팀이 CI 구축을 연기 테스트 할 수 있습니까? 빌드를 중단하지 않았는지 확인하거나 최소한 관리 및 팀 요소를 커밋하고 트리거하지 않고도 일반적인 방식으로 빌드를 중단하지 마십시오.
• CI를 설계하는 방법에 따라 깨진 빌드를 정의하는 방법에는 여러 가지가 있습니다. 여기에는 부서진 정의가 포함됩니다. 과도한 개발 환경에서는 테스트 실패가 실패로 간주되는 것이 아니라 다른 목표로 삼아야합니다.

그러나 당신은 정말로 가지를 봐야합니다.