Java 개발자를 위한 DevOps 도구

5장. 지속적 통합

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

멜리사 맥케이

항상 새로운 실수를 하세요.

에스더 다이슨

2장에서 소스 제어의 가치와 공통 코드 리포지토리에 대해 배웠습니다( ). 소스 제어 솔루션을 구성하고 정착한 후에는 사용자가 제공한 소프트웨어의 완벽한 사용자 경험을 누릴 수 있는 최종 결과물에 도달하기 위해 몇 가지 단계를 더 거쳐야 합니다.

개별 개발자가 전체 소프트웨어 개발 수명 주기에 걸쳐 소프트웨어를 발전시키기 위해 어떤 과정을 거치는지 생각해 보세요. 소프트웨어의 특정 기능이나 버그 수정에 대한 허용 기준을 결정한 후에는 관련 단위 테스트와 함께 실제 코드 줄을 코드베이스에 추가하는 작업을 진행합니다. 그런 다음 모든 단위 테스트를 컴파일하고 실행하여 새 코드가 예상대로(또는 적어도 단위 테스트에서 정의한 대로) 작동하고 알려진 기존 기능을 손상시키지 않는지 확인합니다. 모든 테스트를 통과한 후에는 애플리케이션을 빌드 및 패키징하고 품질 보증(QA) 환경에서 통합 테스트의 형태로 기능을 검증합니다. 마지막으로, 잘 관리되고 유지 관리된 테스트 스위트의 청신호가 켜지면 소프트웨어를 프로덕션 환경에 제공 및/또는 배포합니다.

개발 경험이 조금이라도 있다면 소프트웨어가 그렇게 깔끔하게 제자리를 잡는 경우는 드물다는 것을 잘 알고 계실 것입니다. 개발자 팀과 함께 대규모 프로젝트를 시작하면 앞서 설명한 이상적인 워크플로우를 엄격하게 구현하는 것은 너무 단순합니다. 소프트웨어 배포 라이프사이클에 여러 가지 복잡한 문제가 발생하여 일정에 차질이 생길 수 있습니다. 이 장에서는 지속적 통합과 관련 모범 사례 및 도구 세트를 통해 소프트웨어 개발 프로젝트에서 흔히 발생하는 가장 일반적인 장애물과 골칫거리를 피하거나 완화할 수 있는 방법에 대해 설명합니다.

지속적 통합 채택

지속적 통합 (CI)은 가장 일반적으로 여러 기여자의 코드 변경 사항을 프로젝트의 메인 소스 코드 리포지토리에 자주 통합하는 것으로 설명됩니다. 실제로 이 정의 자체는 약간 모호합니다. 정확히 얼마나 자주라는 뜻일까요? 이 맥락에서 통합이란 실제로 무엇을 의미할까요? 소스 코드 리포지토리에 코드 변경 사항을 푸시하는 것만으로 충분할까요? 그리고 가장 중요한 것은 이 프로세스를 통해 어떤 문제를 해결할 수 있으며 어떤 이점을 위해 이 관행을 채택해야 할까요?

CI라는 개념은 꽤 오래 전부터 존재해 왔습니다. 마틴 파울러에 따르면, 지속적 통합이라는 용어는 원래 12가지 관행 중 하나인 켄트 벡의 익스트림 프로그래밍 개발 프로세스에서 시작되었다고 합니다. DevOps 커뮤니티에서는 이제 이 용어 자체가 토스트에 버터를 바르는 것만큼이나 일반적입니다. 하지만 구현 방식은 팀마다, 프로젝트마다 다를 수 있습니다. 원래의 의도를 완전히 이해하지 못하거나 모범 사례를 포기하면 이점을 제대로 활용하지 못할 수도 있습니다.

시간이 지남에 따라 CI에 대한 이해가 어떻게 ...