지속적 통합 및 지속적 배포 이해

CI/CD를 들었지만 그것이 무엇인지 잘 모르십니까?

이상적으로는 소프트웨어 엔지니어를 고용하여 제품을 필요로 하는 비즈니스에서 사용할 수 있도록 프로덕션 환경으로 배송해야 하는 코드를 작성하는 것이 좋습니다. 비즈니스(종종 사용자/클라이언트라고 함)를 만족시키려면 제품에 버그가 없어야 합니다.

소프트웨어 엔지니어가 따르는 일반적인 접근 방식은 브랜치에서 작업하고 새로운 업데이트로 마스터 브랜치를 업데이트하는 풀 요청을 생성하는 것입니다. 우리는 새로운 변경 사항으로 인해 버그가 발생하지 않도록 테스트를 작성하는 방식을 채택했습니다. 개발자는 대부분의 경우 기능에 대해 작업할 때 기능을 완전히 완료할 때까지 풀 요청을 생성하지 않는 경우가 많습니다. 준비가 되었을 때 일어나는 일입니다.

그들은 작업하는 동안 프로덕션 브랜치에서 발생한 변경 사항으로 코드베이스를 최신 상태로 유지하는 데 많은 시간을 할애합니다.
그렇게 하려면 일련의 병합 충돌을 수정해야 합니다.
또한 프로덕션 브랜치를 깨뜨릴 가능성이 있으며, 이는 문제가 확인되고 수정되기 전에 브랜치를 빼는 사람들에게 계속 영향을 미칩니다.

이런 상황에 처한 적이 있다면 고통스러울 수 있다는 데 동의할 것입니다. 아무도 하루 일과를 이렇게 보내고 싶어하지 않습니다.

해결책은 무엇입니까?

지속적인 통합

위에서 언급한 시나리오를 방지하기 위해; 엔지니어링 팀은 지속적인 통합이라는 방식을 채택할 수 있습니다. 이름에서 알 수 있듯이 개발자가 변경한 코드를 공유 브랜치/리포지토리에 지속적으로 통합하는 방식입니다. 통합할 코드는 애플리케이션을 손상시키지 않도록 검증된 테스트를 거쳐야 합니다. 테스트를 통과해야만 통합됩니다.

이를 이해하기 위해 10명의 개발자로 구성된 팀이 있는 실제 시나리오를 상상해 보겠습니다. 이러한 개발자는 특정 기능의 구현을 위한 코드를 작성하는 분기를 로컬로 만듭니다. 기능이 완전히 완료되었을 때 pull 요청을 보내는 대신 약간의 변경 사항이 있을 때 pull 요청을 보내기로 선택합니다. 이러한 변경의 예는 개발자가 사용자가 애플리케이션의 개별 작업을 관리할 수 있도록 하는 기능에 대해 작업하고 있다고 가정할 때 새 모달을 만드는 것입니다. 작업 기능이 완료될 때까지 기다리는 대신 지속적인 통합 패턴을 고수하기 위해 개발자는 이 작은 변경 사항을 푸시하고(자신이 작업 중인 것과 비교할 때) 코드에 병합하기 위한 풀 요청을 생성합니다.

이 새로운 변경 사항이 통합되기 전에 일련의 테스트를 실행해야 합니다.

소프트웨어 엔지니어링 팀은 다음과 같은 도구를 사용합니다. 트래비스 CI 이러한 통합 프로세스 및 테스트를 생성합니다. 이러한 도구를 사용하면 설정 중에 선택한 대상 분기에 pull 요청이 제출되는 즉시 테스트가 실행되도록 테스트가 자동화됩니다.

테스트 결과가 생성되고 pull 요청을 생성한 개발자는 결과를 보고 필요한 변경을 수행할 수 있습니다. 코드를 가능한 한 적게 통합하는 이 패턴을 고수하고 검증된 테스트를 실행할 때의 이점은 다음과 같습니다.

관련된 팀이 빌드 프로세스 또는 테스트가 실패한 원인을 알 수 있게 됩니다. 이렇게 하면 버그를 프로덕션으로 보낼 가능성이 줄어듭니다.
팀이 프로세스를 자동화하면 생산성에 집중할 수 있는 시간을 가질 수 있습니다.

이 연습에서 주목해야 할 중요한 점은 팀이 코드를 메인 브랜치로 자주 푸시하도록 권장한다는 것입니다. 팀의 다른 구성원이 로컬 리포지토리를 업데이트하기 위해 기본 분기에서 가져오지 않는 경우 이 작업을 수행하는 것은 효과가 없습니다.

테스트 유형

통합 프로세스의 일부가 될 테스트를 작성할 때 프로세스에서 구현할 수 있는 몇 가지 사항은 다음과 같습니다.

통합 – 소프트웨어의 개별 단위를 결합하고 그룹으로 테스트합니다.
단위 – 방법이나 기능과 같은 소프트웨어의 개별 단위 또는 구성 요소를 테스트합니다.
UI – 사용자의 관점에서 소프트웨어가 잘 작동한다고 주장합니다.
승인 – 소프트웨어가 비즈니스 요구 사항을 충족하는지 테스트합니다.

이 중 일부는 이미 개발자가 작성한 코드에 포함되어 있을 수 있으므로 이들 모두를 테스트할 필요는 없다는 점에 유의하는 것이 중요합니다.

지속적 통합 도구

깊이 들어가지 않고 현재 또는 새 프로젝트에서 사용할 수 있는 도구가 있습니다.

트래비스 CI – 오픈 소스 세계에 알려져 있으며 몇 분 안에 코드를 원활하게 테스트할 것을 약속합니다.
서클 CI – 제어에서 배포까지 파이프라인을 자동화할 수 있는 기능, 유연성 및 제어를 제공합니다.
젠킨스 – 모든 프로젝트의 구축, 배포 및 자동화를 지원하는 수백 가지 플러그인을 제공합니다.

Jenkins를 처음 사용하는 경우 이것을 사용하는 것이 좋습니다. 유데미 코스 Java 및 .NET으로 CI를 배우십시오.

지속적인 배포

구축한 기능이 프로덕션 환경에 배포되기 전에 몇 주 또는 몇 달 동안 저장소에 있으면 얼마나 좋을까. 엔지니어링 팀이 작은 변경 사항을 메인 브랜치에 통합하기 위해 노력할 수 있는 한, 가능한 한 빨리 이러한 변경 사항을 프로덕션 환경에 푸시할 수도 있습니다.

지속적인 배포를 연습할 때의 목표는 개발자가 이러한 변경 사항을 메인 브랜치에 통합하는 즉시 사용자에게 변경 사항을 적용하는 것입니다.

지속적 통합의 경우와 마찬가지로 지속적 배포를 사용하는 경우 새로 통합된 변경 사항을 확인하기 위해 자동화된 테스트 및 확인을 설정합니다. 배포는 이러한 테스트를 통과한 경우에만 발생합니다.

팀이 지속적인 배포의 이점을 얻으려면 다음이 준비되어 있어야 합니다.

자동화된 테스트는 모든 지속적인 엔지니어링 관행의 필수 백본입니다. 지속적인 배포의 경우 배포할 코드는 팀이 최종 사용자에게 푸시하려는 내용에 대해 설정한 표준을 충족해야 합니다. 이상적으로는 새로운 변경 사항이 임계값 미만이면 테스트가 실패하고 통합되지 않아야 합니다. 그렇지 않으면 통합됩니다.
자동화된 테스트가 연속적으로 있음에도 불구하고 일부 버그가 프로덕션 환경에 들어갈 수 있습니다. 이를 위해서는 팀이 변경된 사항을 실행 취소할 수 있어야 합니다. 즉, 배포를 실행 취소할 수 있어야 합니다. 이렇게 하면 프로덕션 코드가 새 변경 사항이 적용되기 전의 상태로 되돌아갑니다.
프로덕션 환경에 적용된 변경 사항을 추적하려면 모니터링 시스템이 필요합니다. 이것이 팀이 배포된 변경 사항을 사용할 때 사용자가 발생하는 버그를 추적할 수 있는 방법입니다.

지속적 통합에 대해 언급된 도구는 지속적 배포 시스템을 설정하는 기능도 제공합니다. 당신이 읽을 수있는 많은 것들이 있습니다.

결론

개발 팀의 생산성은 비즈니스의 성공에 매우 중요합니다. 생산성을 보장하려면 이를 장려하는 관행을 채택해야 합니다. 지속적인 통합 및 배포가 그러한 사례의 예입니다.

지속적인 통합을 통해 팀은 매일 가능한 한 많은 코드를 푸시할 수 있습니다. 이를 통해 사용자에게 새로 추가된 변경 사항을 가능한 빨리 배포하는 것이 쉬워집니다. 이러한 변경 사항을 배포하면 사용자로부터 피드백을 얻을 수 있습니다. 결국 비즈니스는 받은 피드백을 기반으로 혁신할 수 있으며 이는 모두에게 윈-윈입니다.

CI/CD를 확장하고 최적화하는 방법도 배울 수 있습니다.

CI/CD 학습에 관심이 있는 개발자라면 다음을 확인하십시오. 화려한 코스.

기사를 재미있게 읽었습니까? 세상과 함께 나누는 건 어떨까요?