메뉴

DevOps의 지속적인 통합

continuous integration devops

문제를 제거하기 위해 도구를 사용해보십시오

DevOps의 지속적 통합이란 무엇입니까?

지금까지이 주제의 1 부와 2 부를 이전 세션과 현재 3 부에서 다뤘습니다.

기술자 인터뷰 질문 및 답변을 지원합니다.

2 부까지 DevOps의 목표를 달성하는 데 도움이되는 팀의 공통 목표, 공통 사고 방식 및 공통 사고에 초점을 맞추고 협업 인 DevOps의 사람과 프로세스 측면에 대해 설명했습니다.

devlops의 지속적인 통합

지난 튜토리얼에서 우리는 다음에 대한 지식을 얻었습니다. DevOps에서 협업을 개발하는 방법 .

확인 => DevOps에 대한 궁극적 인 가이드

지속적 통합, 지속적 테스트, 지속적 배포 및 지속적 배포는 DevOps의 주요 기술적 측면입니다.

비디오 파트 3 블록 1 : 지속적인 통합– 12 분 20 초

성적 증명서:

마지막으로부분에서 우리는 DevOps 관행에 의해 채택 된 애자일 원칙의 부분을 배운 DevOps 관행을 배웠습니다.

이러한 원칙을 통해 DevOps의 목표는 어떻게 달성됩니까?

우리는 버전 제어, 자동화 및 고객에게 작은 가치 증가와 그 혜택을 제공하는 것의 중요성을 연구했습니다.

DevOps의 맥락에서 협업이란 무엇이며이를 어떻게 달성합니까?

지금까지 DevOps의 사람과 프로세스 측면, 즉 공동 작업 인 DevOps의 목표를 달성하는 데 도움이되는 팀 내 공통 목표와 공통 사고 방식 및 공통 사고에 초점을 맞추 었습니다. 이제 DevOps의 몇 가지 기술적 측면에 대해 알아 보겠습니다. , DevOps 릴리스를 가능하게합니다.

이는 지속적 통합, 지속적 전달 및 배포 및 지속적 테스트입니다.

파트 3의 블록 1의 일부로 먼저 '지속적인 통합'.

지속적 통합이란 무엇입니까?

지속적인 통합-> CI-> 프로세스 세트-> 파이프 라인 / CI 파이프 라인 구축

DevOps에서 'CI'라고도하는 지속적 통합은 'Build Pipeline'또는 'CI Pipeline'이라는 파이프 라인의 일부로 정의되고 수행되는 중요한 프로세스 또는 일련의 프로세스입니다.

DevOps 관행에는 개발 및 운영 팀 모두를위한 단일 버전 제어 도구가 있으며, 여기에서 모든 사람의 코드가 마스터 코드 기반으로 저장되어 팀이 병렬로 작업 할 수 있습니다.

따라서 DevOps에서 지속적 통합은 개별 개발자 코드를 버전 제어가 유지되는 메인 브랜치 코드의 마스터 사본에 병합하는 것입니다. 하루에 발생해야하는 코드 병합 시간에는 제한이 없습니다.

개발자가 코드를 버전 제어에 체크인하면 즉시 CI 킥 프로세스가 시작됩니다.

두 숫자 사이의 C ++ 난수 생성기

CI 프로세스에는 다음이 포함됩니다.

  1. 모든 개발자 코드를 메인 라인에 병합,
  2. 빌드 트리거,
  3. 코드를 컴파일하고 빌드하고…. 마지막으로
  4. 단위 테스트를 수행합니다.

따라서 지속적 통합은 모든 개발자의 코드를 중앙 위치에 병합하고 자동화 된 빌드 및 테스트를 통해 각각의 병합을 검증하는 프로세스입니다.

CI 동안 일어나는 일을 기술적으로 설명하기 위해

지속적인 통합을위한 서버가 있습니다. CI 도구 , 코드 체크인을 위해 버전 관리 도구를 계속 감시하고 체크인이 발견되는 즉시 자동 컴파일을 트리거하고 정적 코드 분석 및 기본 수준의 자동화 된 보안 테스트와 함께 단위 테스트를 빌드 및 실행합니다. .

Jenkins, TestNG, 단위 테스트를 수행하는 NUnit, 정적 코드 분석을 수행하는 Sonar, 보안 테스트를 수행하는 강화 등 자동화 된 테스트를 수행하기위한 다양한 도구가 모두 CI 파이프 라인과 통합됩니다. .

따라서 전체 CI 파이프 라인은 수동 개입없이 자동화 된 프로세스이며 몇 초 또는 몇 분 내에 실행됩니다.

따라서 CI의 주요 이점은 개발자가 시간 내에받는 빠른 피드백입니다.

  1. CI는 개발자가 코드를 확인하고 몇 초 만에 결과를 내 보낸 후에 실행됩니다. 따라서 개발자는 자신의 코드가 성공적으로 빌드되었는지 또는 손상되었는지 즉시 알 수 있습니다.
  2. 또한 개발자는 자신의 코드가 다른 사람의 코드와 성공적으로 통합되었는지 또는 손상되었는지, 다른 팀 구성원이 코드베이스의 다른 부분에 수행 한 작업을 알 수 있습니다. 따라서 CI는 더 빠른 코드 분석을 수행하고 나중에 병합 할 때 더 간단하고 오류가 없도록합니다.

따라서 CI는 모든 코드 체크인시 빌드가 트리거되고, 컴파일되고, 빌드를 만들고, 자동화 된 단위 테스트가 빌드에서 실행되는 자동화 된 프로세스입니다.

CI 프로세스는 각 체크인마다 즉시 컴파일 및 빌드하고 잘못된 코드 인 경우 오류를 발생시키기 때문에 팀에있는 모든 사람의 코드가 좋은지 또는 유효한지 확인하는 COP 또는 프로세스라고도 할 수 있습니다. 또는 컴파일 할 수 없거나 자동화 된 단위 테스트 케이스를 통과 할 수 없습니다.

CI의 이점은 무엇입니까?

우선, 전체 CI 프로세스는 자동화 된 프로세스이므로 버그를 유발하는 긴 수동 병합을 줄여 인적 오류를 최소화합니다.

다른 사람이 코딩을 완료 할 때까지 기다릴 필요없이 하루에 몇 번이라도 코드를 체크인 할 수 있습니다. 체크인이 끝날 때까지 기다렸다가 체크인 할 수 있습니다. 따라서 CI는 종속성을 제거하거나 다른 사람이 체크인하는 대기 시간을 제거합니다.

따라서 팀 구성원은 다른 팀 구성원이 체크인을 완료 할 때까지 기다릴 필요가 없으므로 병렬로 작업 할 수 있습니다.

모든 체크인은 버전 관리에서 수집되는 데 그치지 않고 빌드 형성 및 자동화 된 테스트를 통해 즉시 검증됩니다. 따라서 각 체크인은 추가 처리를 위해 루트 자체에서 검증됩니다.

모든 사람의 코드가 타임 스탬프와 함께 마스터 사본에 체크인되어 올바르게 기록되기 때문에 다른 사람의 코드를 놓칠 가능성이 없습니다.

컴파일, 빌드 및 테스트의 전체 프로세스가 몇 초 만에 실행되므로 훨씬 더 빠르고 빠르고 많은 시간을 절약 할 수 있으므로 몇 시간 동안 더 빠르게 제공하는 DevOps 목표를 달성하는 데 도움이됩니다.

빌드 및 테스트의 전체 프로세스가 몇 초에서 몇 분에 걸쳐 실행되기 때문에 개인의 코드에 대한 피드백이 매우 빠르며 모든 코드가 빌드를 손상 시키거나 결함을 유발 한 코드를 찾기 위해 돌아 다닐 필요가 없습니다. 체크인은 실패가있는 경우 실패 영역을 나타내는 성공 또는 실패 출력을 제공합니다.

따라서이를 통해 개발자는 간헐적으로 소량의 코드 (아마도 한 줄의 코드)를 확인하여 오류가 없는지 확인하고 개발자가 자신의 코드가 훌륭하고 다른 코드를 손상시키지 않는다는 확신을 가질 수 있습니다. 암호. 따라서 이것은 전체적으로 코드의 품질을 향상시키는 데 도움이됩니다.

여기서 잠시 멈추고 다음 비디오 자습서에서 지속적 배포 및 지속적 테스트를 선택하겠습니다.

이전 튜토리얼 | NEXT 튜토리얼

추천 도서

^