지속적인 통합 시스템 베이비 시팅

팀에서 저의 역할 중 하나는 빌드 담당자 입니다. 빌드 스크립트를 유지 관리 / 업데이트하고 지속적인 통합 서버에서 '부드럽게'구축하고 있는지 확인해야합니다. CI 서버를 계속 돌보는 것처럼 느껴지지만 대개이 작업은 신경 쓰지 않습니다.

빌드가 중단되면 작업중인 스토리를 삭제하고 빌드 실패를 조사해야하기 때문에이 작업은 때때로 성가시다. 팀에서 매일 빌드 실패가 발생합니다. 때로는 개발자가 커밋하기 전에 로컬에서 빌드하지 않기 때문에 CI 서버에서 테스트가 실패합니다. 이 상황에서 나는 '나쁜 커밋'을 한 사람에게 빨리 접근하여 빌드가 너무 오래 중단되지 않도록합니다. CI 서버에 디버깅해야하는 이상한 조건이있는 경우가 있습니다.

많은 성숙한 팀이 Continuous Integration을 사용하지만 모범 사례에 대한 자료는 많지 않습니다.

내 문제는 지속적인 통합이 그다지 성숙하지 않았거나 이것이 단순히 일의 일부라는 것을 지적합니까?

따라야 할 모범 사례는 무엇입니까? 성숙한 지속적인 통합 의 특징은 무엇입니까 ?

최신 정보

몇 가지 의견에 대답하는 대신 업데이트를 할 것입니다. 앱을 빌드 할 때 빌드 서버가 수행 할 작업을 정확하게 수행하는 하나의 간단한 명령이 있습니다. 컴파일, 모든 유닛 / 통합 및 빠른 UI 기반 테스트를 실행합니다.

모든 사람의 대답을 읽으면 두 가지 큰 문제가 있다고 생각합니다.

1. 빌드가 실패 할 때 CI 서버가 충분히 크게 불평하지 않습니다.
2. 개발자는 자신의 커밋이 성공적으로 수행되도록 모든 사람이 책임감을 느끼지 않습니다.

팀에서 일을 더 어렵게 만드는 것은 큰 팀 (10 명 이상의 개발자)이 있고 심지어 근무 중이 아닐 때 커밋하는 두 명의 해외 팀 구성원이 있다는 것입니다. 팀이 크고 우리는 빈번하고 작은 커밋이 선호된다는 것을 확립했기 때문에 때로는 하루에 많은 활동을하게됩니다.

가장 먼저 : 각 사람은 빌드 프로세스를 담당합니다 . 팀 구성원이 성숙하지 않은 것 같습니다. 아무도 코드를 작성하고 CI 서버로 가져 와서 작동한다고 생각하지 않습니다. 코드를 커밋하기 전에 로컬 컴퓨터에서 테스트해야합니다. 당신은해야 확실히 당신이 확인하고 코드가 빌드를 중단하지 않을 것이다. 물론, 실수로 빌드가 중단되는 경우가 있습니다 (예 : 구성 파일이 변경되었거나 실수로 커밋 된 경우).

대부분의 CI 서버 (허드슨 만 사용함)는 빌드가 중단 된 커밋에 대해 자세히 설명하는 자동 전자 메일을 보냅니다. 당신의 역할의 유일한 부분은 용의자가 파산 한 것을 고칠 때까지 힘들어 보이게하는 것입니다.

당신의 팀은 한가지 잘못을 발견했습니다 :

빌드 서버 에 대한 책임은 빌드에 대한 책임과 다릅니다 .

코드를 체크인하는 것은 (일의 가치를 위해) "일하기"위한 책임입니다. 빌드 서버가있는 유일한 이유는이 프로세스에서 감독을 포착하기위한 것입니다. 그 가치가있는 빌드 서버는 마지막 빌드 이후 코드를 체크인 한 사람 (및 관심있는 다른 사람)에게 다음 정보를 알릴 수 있습니다.

• 파산!
• 건축 할 때 무엇이 ​​잘못 되었습니까!
• 마지막 빌드 이후 변경된 내용!

이것은 매우 자주 이메일로 발생합니다. 체크인 할 때마다 매우 빠르게 발생하는 것이 중요합니다.

그러면 사람은 무엇이 잘못되었는지 확인할 수 있고 수정하면 빌드 서버는 관심있는 사람에게 빌드가 정상으로 돌아 왔다고 알립니다. 이는 체크인 범인이 아닌 다른 사람의 개입없이 스스로 발생해야합니다.

따라서 귀하의 질문에 대답하십시오. 성숙한 CI 환경에서는 정상적인 운영에 관리인이 관여 할 필요 가 없습니다 .

또한 "이상한 조건이 존재하는 경우"가 자주 발생하면 원인을 찾아 시스템을보다 강력하게 만듭니다.

프로세스를 변경하십시오. 커밋이 빌드를 중단하면 해당 커밋을 자동으로 롤백하고이를 위반 한 개발자에게 알립니다. 한 팀 구성원이 오류를 허용하여 나머지 팀의 속도를 늦추는 것은 어리석은 일입니다. 또는 통합 빌드를 자동으로 수행하는 대신 개발자에게 통합 시스템을 확인하도록하고 빌드가 성공하면 커밋 할 수 있습니다. 지속적인 통합은 "당신이 좋아하는 정크를 확인하고 누군가가 당신을 위해 그것을 고칠 것"을 의미하지 않습니다.

"골든 브랜치"전략은 골든 브랜치의 게이트 키퍼가 없으면 작동하지 않습니다.

Git과 같은 DVCS가 도움이 될 수 있습니다. 커밋하는 대신 개발자는 CI 서버에 통합하기 위해 변경 세트를 제출하면 서버가 변경 세트 통합을 시도 할 수 있습니다. 통합이 성공하면 변경 세트가 병합되고 그렇지 않은 경우 거부됩니다.

필자가 종종 보게되는 한 가지 문제는 개발자 가 CI 빌드 와 정확히 동일한 단계 를 가진 로컬 빌드를 수행 할 수 없다는 것 입니다. 즉, CI 서버는 로컬로 수행 할 수없는 단위 / 통합 테스트, 적용 범위 등과 같은 추가 단계를 포함하도록 구성됩니다. 필연적으로 개발자는 로컬에서 수행 할 수없는 단계 중 하나에 물 렸고 체크인 전에 로컬에서 릴리스를 구축하는 데 왜 귀찮은 지 궁금해하기 시작합니다.

전체 빌드를 독립적으로 유지하고 CI 서버가 외부 구성 / 단계가 정의되지 않은 릴리스 빌드를 시작하도록합니다. 개발자는 체크인 전에 CI 빌드에서 수행 할 모든 단계를 포함하여 릴리스 빌드를 로컬로 실행할 수 있으며 체크인 할 때 아무것도 중단되지 않을 것이라는 확신을 가질 수 있습니다.

이 접근법에 추가 된 이점은 다음과 같습니다.

• 불필요한 단계를 구성하는 데 많은 시간을 투자하지 않았기 때문에 CI 서버간에 쉽게 전환 할 수 있습니다.
• 모든 빌드 타임 툴링은 소스 제어하에 있으며, 이는 모든 개발자가 정확히 동일한 툴 세트를 사용하여 시스템을 빌드하고 있음을 의미합니다
• 위의 사항 외에도 제어 도구로 빌드 툴링을 변경하는 것이 간단합니다.

추신. 전체 빌드 베이비 시터 개념은 어리석은 일이지만 다른 사람들은 그것을 다루었습니다.

첫째, 개발자는 정기적으로 빌드를 중단해서는 안됩니다. CI 지점에 커밋하기 전에 로컬에서 테스트를 빌드하고 실행해야합니다. 빌드를 깨뜨리는 것은 수치심의 표시가되어야합니다. 통계 게시를 통해이 작업을 수행했으며 다른 팀에 빌드를 중단 할 때마다 1 달러를 넣는 "빌드 백"이있는 것을 보았습니다. 프로젝트가 끝나면 그 돈은 맥주를 향합니다.

수치심 / 개인적 자존심이 효과가 없다면, 더 무거운 물건으로 옮겨야 할 수도 있습니다 (예 : 해지 위협). 하루를 떠나기 전에 빌드를 깨는 것은 중대한 범죄입니다. 또한 모든 개발자는 데스크톱에 빌드 상태 알림이 있어야합니다. 이 모든 것의 가장 좋은 부분은 작은 커밋을 장려한다는 것입니다. 어쨌든 선호됩니다.

즉, 빌드가 때때로 중단 될 수 있습니다 (예 : CI 구성 이유). 그리고 때때로 사람들은 건물이 망가진 채 하루를 망치고 떠날 것입니다. 따라서 알려진 양호한 버전으로 빠르고 쉽게 롤백 할 수있는 프로세스를 목표로해야합니다. 항상 마지막으로 성공한 빌드로 롤백하고 롤백 버전을 필요한 모든 위치에 배포 할 수 있다면 최악의 경우 범인이 저녁 동안 떠난 빌드가 고장난 시나리오에서 롤링 할 수 있습니다 마지막으로 좋은 버전으로 돌아가 아침에 소리 지르십시오.

Continuous Delivery 책을 충분히 추천 할 수 없습니다 . CI 프로세스를 성숙시키는 방법에 대한 가이드를 찾고 있다면 시도해보십시오.

Microsoft (아마도?)가하는 일에 대해 들었습니다. 팀을 돌보는 베이비 시터의 역할을하는 것입니다. 그들이하는 방법은 누군가가 빌드를 깨뜨릴 때 (아마도 테스트에 실패한 것을 체크인하는 것을 포함해야 할 때), 그 역할을 맡는 것입니다. 이것은 사람들이 그들의 행동의 결과에 대해 매우 직접적인 방식으로 책임을지게합니다. 그리고 그것은 다소 성가신 일이기 때문에 다시 빌드를 중단하지 않도록 권장합니다.

현재 빌드를 담당하는 사람에게는 특별한 모자가있을 수 있습니다. 그것을 넘겨주는 행사가있을 수 있습니다.

Thorbjørn이 말했듯이 빌드에 대한 책임은 빌드 서버에 대한 책임과 동일하지 않습니다. 서버에 대한 책임은 빌드에 대한 책임이 이동하면서 하나 이상의 인프라 적으로 기울어 진 팀 구성원과 영구적으로 휴식을 취할 수 있습니다.

이제 프로세스의 세부 사항을 제쳐두고 빌드 및 테스트를 실행하지 않고 체크인하는 개발자에게 불만을 표현하는 사람들의 합창에 합류 할 것입니다. 용납 할 수 없습니다!

팀원 중 일부가 빌드를 중단 할 가능성이 더 높은 경우 (나 자신의 경험을 바탕으로 대부분 다른 국가의 멤버를 생각하고 있음) Mercurial과 같은 멋진 최신 소스 제어를 사용하는 경우 또는 Git, 팀의 다른 지점에 다른 지점에 체크인하고, 별도의 CI 프로세스를 실행하고, 성공적인 빌드 후 해당 지점에서 트렁크로 변경 사항을 자동으로 병합하도록 할 수 있습니다. 병합을 체크인하기 전에 두 번째 빌드를 실행하고 병합 후에 테스트하십시오!). 자동 병합이 항상 성공적인 것은 아니기 때문에 결국 지점에 수동적 인주의가 필요하지만 실제로는 고통이 될 수 있습니다. 그래도 팀의 나머지 부분에 깨진 코드를 체크인하는 것보다 고통스럽지 않을 수 있습니다.

Jonathan Khoo가 말했듯이 빌드 서버와 빌드 스크립트는 모두 책임 져야합니다. 세 가지 이유가 있습니다.

1. 현재 "버스 1"의 사례가 있습니다. 즉, 버스로 인해 오버로드되면 빌드 서버 및 빌드 스크립트에 대한 모든 지식이 손실됩니다.
2. 귀하가 (올바르거나 잘못) 작성한 스크립트는 입력 내용 만 가지고 있습니다. 다른 코드와 마찬가지로 더 많은 사람들이 참여할 수있는 지식 기반은 더 넓습니다.
3. 마지막으로 무언가 잘못되면 당신은 고통을 느끼고 있습니다. 통증은 좋은 것이지만 고립되었을 때는 아닙니다. 현재 당신은 고통을 다루고 있지만 다른 사람들이 고통을 겪고 있다면 커밋하기 전에 코드를 테스트하는 것이 더 엄격하다는 것을 알 수 있습니다.

저는 CI와 매우 관련이 있으며 스크립트를 유지 관리하는 사람이되는 함정에 빠지지만이를 완화하기 위해 할 수있는 몇 가지 작업이 있습니다.

1. 빌드 스크립트는 CI 서버뿐만 아니라 로컬 개발 시스템에서도 실행되어야합니다. 동일한 출력을 생성하고 동일한 테스트를 실행하며 같은 이유로 실패해야합니다. 이를 통해 개발자는 코드를 커밋하기 전에 스크립트를 실행할 수 있습니다.
2. 작업 트레이 팝업, 전자 메일, 깜박이는 표시 등, 소음 등을 사용하여 빌드를 중단 한 사람이 있으면 팀 구성원을 당황하게 할뿐만 아니라 팀의 다른 모든 사람이 뛰어 넘을 수있는 기회를 제공합니다. 돕다.
3. 잠시 동안 빌드를 수정하지 마십시오. 다른 사람이 그렇게하도록하십시오. 아무도 뛰어 오르지 않으면 나쁜 일이 생길 때까지 기다렸다가 전체 팀이 CI 서버가 중요한 이유를 이해할 수있는 학습 지점으로 사용하십시오.
4. 빌드 서버 및 개발 시스템을 가능한 한 많이 설치된 타사 구성 요소없이 유지하고 특히 GAC를 깨끗하게 유지하십시오. 프로젝트 라이브러리 폴더에있는 타사 구성 요소를 사용하십시오. 이를 통해 누락 된 구성 요소를보다 빠르게 식별 할 수 있습니다.

가시성이 도움이 될 것입니다. 모든 팀원은 해결해야 할 적극적인 문제가 있음을 알아야합니다. 이메일 알림은 유용하지만 개발자가 바쁘고 바로 반응하지 않으면 이메일을 잊어 버릴 수 있으며 이메일에 큰 알림이 표시됩니다.

Catlight 또는 BuildNotify 와 같은 도구를 사용해 볼 수 있습니다 . 트레이 영역에서 중요한 빌드의 현재 상태를 보여줍니다. 개발자가 시계를 볼 때마다 수정해야 할 손상된 빌드가 있음을 알 수 있습니다.

Catlight는 또한 전체 팀이 각각의 연속적인 빌드 실패에서 볼 수 있기 때문에 누가 먼저 빌드를 깨뜨 렸는지 보여줍니다.

하나의 전략은 많은 작은 프로젝트에 많은 작은 가지를 사용하는 것입니다. 그런 다음 누군가 빌드를 중단하면 빌드 자체가 중단됩니다. 따라서 그들은 빌드 서버에서 성가신 이메일을 받고 걱정할 것입니다.

다른 하나는 사람들의 책임 수준을 향상시키는 것입니다. 예를 들어 Rietveld 와 같은 것을 사용하면 사람들은 동료 검토를 통과하지 않고 커밋 할 수 없습니다. (실제로 진행되는 프로세스는 생각보다 훨씬 가볍습니다. 그러나 사람들이 한 번에 "파이프 라인"하고 여러 작업을 수행하도록 강요합니다.) 빌드를 보존하는 것은 커미터와 검토 자의 책임입니다. 누군가 정기적으로 빌드를 중단하거나 빌드를 중단시키는 것을 승인하는 경우 커밋에 대한 최종 승인을 허용하지 마십시오. 누구나 쉽게 변경 사항을 롤백 할 수있는 프로세스와 결합하면 빌드가 자주 중단되지 않으며 변경 한 후에도 계속 중단되지 않습니다.

나는 여기서 코러스를 깨고 실제 빌드가 이루어지고 있음을 보여주기 때문에 실제로 빌드를 깨는 것은 그렇게 나쁘지 않다고 말합니다. 그렇습니다. 개발자는 커밋하기 전에 빌드하고 테스트해야하지만 테스트의 주된 부담은 지속적인 통합 서버를 포함한 개발 자동화 도구가 부담해야합니다. 도구를 사용할 수 있으며, 빌드가 계속 중단되지 않는 한 최대한 열심히 노력하고 있는지 확실하지 않습니다. 그러나 빌드가 상당한 시간 동안 중단되어서는 안되며 중앙 집중식 자동 테스트 시설의 빠른 피드백이라는 두 가지 목표를 지원하는 경우 자동 롤백 또는 다단계 커밋 프로세스를 선호합니다. "녹색"트렁크와 함께.

명심해야 할 사항 :

1. 팀은 따라야 할 표준 세트가 필요합니다
2. 깨끗한 코드라는 아이디어로 경영진을 선발하고 개선 된 코드 관행을 위해 노력해야합니다.
3. 테스트 테스트 테스트! 체크인하기 전에 항상 테스트하십시오.
4. 비록 빌드를 중단해도 괜찮다는 데 동의하지만, 이는 드문 일이며 허용 가능한 극도로 드문 경우를 의미합니다. 이것이 매일이라면 문을 찾거나 표준에 대해 상사와 이야기하고 있습니다.

전반적으로 여러분은 모범 사례를 기반으로 표준을 작성하고 모범 사례를 기반으로 표준을 작성해야합니다. 모든 사람이 표준에 동의하면 코드 검토 프로세스를 시작하고 표준을 시행하십시오. 경영진이 휴가를 마치고 다시는 돌아 오지 않은 것처럼 들립니다. 이것들은 모든 상점에서 솔직히 기본 사항입니다. 좋은 코드의 기초는 팀 코드와 그 작성 방법을 지시하는 좋은 표준으로 시작합니다. 그냥 내 생각 나는 최근에 새로운 직장에서 비슷한 상황에 들어갔고 상사와 이야기를 나 ed습니다. 그에게 ABC에 영향을 미치기 때문에 XYZ를 완료해야한다고 설명했습니다. 2 주 후에 나는 따라야 할 코드 표준 목록을 작성하고 제시했다. 저의 동료 직원들에 의해 정보를 제공했고 약 2 개월 후에 우리는 수많은 문제를 해결하는 표준을 마련했습니다.