야간에 코드를 빌드하는 자동 빌드 서버가 있습니다. 팀원 모두가 전체 소스 트리를 빌드 할 수있는 것은 아니기 때문에 우리에게 유용합니다. 최근 팀원 중 일부는 빌드 오류를 신속하게 수정하는 데 더 편한 자세를 취하고 있습니다. 때로는 성공을 거두지 못해 몇 주가 지나기도합니다. 한 개발자가 "빌드가 이미 망가 졌으므로 이제는 몇 가지 변경 사항을 추가 할 수있는 좋은 시간"이라고 들었습니다. 가장 먼 다운 스트림에서 작업하기 때문에 일반적으로 소스 코드 저장소와 동기화되지 않은 부분과 함께 작업하기 때문에 제출하기 전에 변경 사항을 테스트하기가 매우 어렵습니다.야간 빌드를 신속하게 수정하는 것이 얼마나 중요합니까?
계속 깨지기 때문에 밤에 지을 수 있다는 이점을 대부분 잃어 버리고있는 것 같습니다. 내가 여기서 벗어나거나 빌드를 고쳐야할까요?
야간 빌드를 고정하는 것이 가장 중요합니다. 당신이 말했듯이, 그들이 부서지면 그들은 가치가 없습니다. 사람들이 파손을 일으키는 코드를 체크 인하길 원한다면, 브랜치에서이를 수행해야하며 테스트를 마친 후에 만 병합해야합니다.
이러한 개발자는 분명히 모양으로 되돌릴 필요가 있습니다.
나는 체크인을하지 않을 경우 매일 적어도 몇 번씩 건물을 지을 것을 제안합니다. 일단 성공적인 빌드 사이클을 다시 거치게되면 빌드를 파기 한 사람에게 (농담으로)가 봅니다.
누구나 코드베이스의 소유권을 가져야하고 책임을 져야합니다.
솔직히 말해서, 그것은 또한 당신의 기술에 자부심을 가지고 있습니다. 궁극적으로 사람들이 빌드가 망가졌지만 빌어 먹을 것을 요구하지 않고 빌려주지 않는다면 다른 일을하는 것이 나을 것입니다.
빌드에는 몇 시간이 걸리므로 모든 변경 작업을 실제로 구현할 수는 없습니다. 나는 사람들이 빌드가 망가 졌음을 모르는 것이 아니라, 그들이 신경 쓰지 않는다는 것이 문제가 아니라고 생각한다. –
그런 다음 하위 구성 요소 빌드로 구조를 재구성해야합니다. 이미 제작 된 인공물을 사용하여 코드가 변경되지 않은 경우 참조 할 수 있습니다. –
사람들이 신경 쓰지 않는 것이 문제라면, 깨진 빌드가 가장 적은 문제입니다. –
고칠 때가 길어질수록 수정할 시간이 길어집니다.
즉시 해결되면 모든 사람의 머리가 부서지기 쉽습니다. 변경 사항을 깨면 나중에 수정할 수있는 골칫거리가 될 수 있습니다.
우리는 실제로 이런 일이 발생했다. 급격한 변화는 빌드의 후반부에 소개되었지만 2 주 후까지는 볼 수 없었습니다. –
고정시켜야합니다. 더 오래 버리면 나중에 더 많은 것들을 발견 할 수 있습니다. 클린 빌드로 시작하지 않으면 변경 사항이 빌드를 손상 시켰는지 어떻게 알 수 있습니까?
우리의 표준은 모든 유닛과 기능 테스트를 커밋 후 중립적 인 통합 상자에서 "녹색"으로 실행하는 것입니다. 물론 테스트 주도 개발은 우리 상황에 적절하지만 사용자에게 적합하지 않을 수 있습니다. 프로젝트를 빌드 할 수조차 없다면, 이전 커밋에 숨어있는 것이 놀랄 것입니다.
빌드하는 데 걸리는 시간이 너무 길어서 고정 된 방식으로 작동하는 경우 작은 프로젝트로 분할하고 지속적인 통합과 같은 기술을 사용하면 도움이 될 수 있습니다.
내 친구가 내 생각에 운명의 주 치니를 가진 그의 팀에 대해 이야기했습니다. 야간 빌드를 깨는 사람은 누구나 책상에 ZoD를 표시해야했습니다. 이 채소는 상당히 진보 된 상태의 분해 상태였으며, 깨진 구조물이 용납 될 수있는 것이 아니라는 것을 아주 분명하게 보냈습니다.
팀이 야간 건물을 지킬만큼 의욕적 인 것이 아니라면 이는 관리자가 시행/권장해야하는 것입니다.
아마도 행동을 함께하지 않으면 아웃소싱으로 위협해야합니다.:) –