감독되지 않은 많은 주니어 개발자들이 수년에 걸쳐 자연스럽게 진화 한 Big Ball Of Mud 코드베이스에 대한 과거의 경험을 바탕으로 개발자들과 CI를 연습 하지 않을 때 어떤 일이 발생하는지 지적하고 싶습니다 .
편집 / 업데이트 : RubberDuck의 의견에 따라; 이 답변에서는 통합을위한 병합 대상이 평가 또는 릴리스 분기가 아닌 개발 분기라고 가정합니다.
- 릴리스 및 라이브 배포를 위해 코드를 훨씬 더 많이 제어해야합니다. 별도의 프로덕션 브랜치가없는 경우 마스터 릴리스 브랜치와 함께 마스터 개발 브랜치 (통합 테스트에 사용되며 릴리스에는 사용되지 않음)를 실행하기 위해 브랜칭 / 병합 전략을 변경하는 것이 좋습니다. 이를 통해 CI의 모든 이점을 유지하고 생산 코드를 위반하지 않고 자주 병합합니다.
1. 주니어 개발자는 동료 또는 감독자와 의사 소통 할 가능성이 적습니다.
지속적인 통합은 단순히 코드를 병합하는 문제가 아니라 개발자가 다른 이해 관계자와 상호 작용해야하는 시점입니다.
의사 소통은 중요하며, 지나치게 일반화하기를 원치 않으면, 팀 환경에서 일하는 데 익숙하지 않은 숙련 된 개발자보다 경험이 부족한 개발자에게 덜 자연스럽게 전달되는 학습 기술인 경향이 있습니다.
주니어 개발자가 빈번한 보고서 / 검토를 요청하지 않고 큐비클에 앉아 몇 주 동안 코드를 쏟아 내면 의사 소통을 완전히 피할 가능성이 높습니다.
2. 그들이 생성하는 코드는보다 엄격한 검토가 필요할 것입니다
당신은 당신이 이전에 그것을 집어 들고 그것을 작성하는 것을 막기를 원했을 정도로 나쁜 것을 검토 한 적이 있습니까? 이것은 많이 일어난다.
잘못된 코드가 작성되는 것을 막을 수는 없지만 낭비되는 시간을 제한 할 수 있습니다. 빈번한 검토 및 병합을 약속하면 낭비되는 시간 범위를 최소화합니다.
최악의 시나리오는 자신의 미니어처 프로젝트에서 주니어 개발자를 몇 주 동안 방치 할 수 있으며, 최종적으로 코드 검토를 준비 할 때 전체 혼란을 겪을 시간이 충분하지 않다는 것입니다. 처음부터 다시 시작하십시오.
너무 늦을 때까지 아무도주의를 기울이지 않을 때 나쁜 코드가 가득 찼기 때문에 많은 프로젝트가 진흙탕 이되었습니다.
3. 주니어 개발자 또는 다른 새로운 팀원이 요구 사항을 이해했음을 확실하지 않습니다.
때때로 개발자는 잘못된 문제에 대한 완벽한 솔루션을 구축 할 수 있습니다. 누군가가 프로세스 초기에 올바른 질문을했을 경우 피하기 쉬운 간단한 오해로 인해 이것은 슬픈 일입니다.
다시 말하지만, 이는 요구 사항의 지혜를 묻지 않고 반박 할 때 액면가에서 "나쁜"요구 사항을 받아 들일 가능성이있는 경험이없는 개발자에게 영향을 줄 수있는 문제입니다.
4. 일반적인 패턴, 기존 코드의 아키텍처 및 잘 알려진 도구 및 솔루션에 익숙하지 않을 수 있습니다.
때로는 개발자가 더 나은 솔루션이 존재한다는 것을 몰랐기 때문에 불필요하게 바퀴를 다시 발명하는 데 많은 시간을 소비합니다. 또는 그들이 잘못하고있는 것을 깨닫지 않고 사각 구멍을 둥근 구멍으로 망치려고 노력하는 데 며칠이 걸릴 수 있습니다.
다시 말하지만, 이런 종류의 경험은 경험이 부족한 개발자에게 발생할 가능성이 높으며 문제를 해결하는 가장 좋은 방법은 정기적 인 검토를 보장하는 것입니다.
5. 코드 커밋 / 병합 사이의 오랜 기간 동안 결함을 식별하고 수정하기가 더 어려워 짐
몇 주 분량의 코드 변경 사항이 마스터 브랜치에 병합 된 직후 버그가 발생하면 어떤 변경으로 인해 버그가 발생했는지 파악하기가 더 어려워집니다.
분명히 전체 분기 전략도 여기에 적용됩니다. 이상적으로 모든 개발자는 자체 브랜치에서 작업하거나 기능 브랜치에서 작업하거나 마스터 / 트렁크에서 직접 작업하지 않습니다.
전체 팀이 모두 마스터 / 트렁크에서 동시에 직접 작업하는 상황을 보았습니다. 이는 CI의 끔찍한 환경이지만, 운 좋게도 마스터 / 트렁크에서 모든 사람을 끌어내는 솔루션은 일반적으로 개별 작업에 충분한 안정성을 제공합니다. 품목 / 티켓 / 등
병합이 정기적으로 이루어져야한다는 점을 이해하고 변경 사항과 결함을보다 신속하게 식별해야하므로 더 빨리 해결 될 수 있다는 점을 이해하면 모든 개발자가 마스터 / 트렁크 브랜치 를 중단 하는 것은 항상 "OK" 여야합니다. 최악의 결함은 일반적으로 몇 달 또는 몇 년 동안 발견되지 않은 결함입니다.
요약해서 말하자면; 지속적인 통합 / 연속 배포의 주요 장점은 다음과 같습니다.
- 팀 간의 커뮤니케이션이 향상됩니다
- 코드 품질은 일반적으로 더 높은 표준으로 유지됩니다
- 요구 사항을 놓치거나 잘못 해석 할 가능성이 적습니다.
- 아키텍처 및 디자인 문제는 더 빨리 감지되어야합니다.
- 결함은 초기 단계에서 감지되고 수정 될 가능성이 더 높습니다
따라서 하급 개발자와 함께 CI를 연습하지 않으면 나머지 팀원보다 더 많은 팀원이 필요하기 때문에 불필요한 위험을 많이 수용하게됩니다.
it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (...), and auto deploy to production as soon as your commit passes as tests on stageIMHO는 모 놀리 식 접근 방식보다 독립적 인 서비스 배포를 통한 성공을 보장하기가 훨씬 어렵습니다 : softwareengineering.stackexchange.com/a/342346/187812 . 그리고 진정한 CI (기능 / 통합 지점 없음)를 사용하면 일주일을 기다릴 필요가 없습니다.