지속적인 통합에 대한 간단한 설명

Continuous Integration을 어떻게 정의하고 CI 서버에 포함 된 특정 구성 요소는 무엇입니까?

Continuous Integration이 무엇인지 마케팅 부서의 누군가에게 설명하고 싶습니다. 소스 제어를 이해합니다. 즉, Subversion을 사용합니다. 그러나 CI가 무엇인지 제대로 설명하고 싶습니다. 위키 백과의 기사 결코 제대로 정의의 마틴 파울러의 문서 만 기본적으로 '통합'의 모호한 설명에 이어 동어 반복이다 다음을 제공합니다 :

Continuous Integration은 팀 구성원이 작업을 자주 통합하는 소프트웨어 개발 관행입니다. 일반적으로 각 사람은 매일 최소한 하루를 통합하여 하루에 여러 번 통합합니다. 각 통합은 자동 빌드 (테스트 포함)로 검증되어 통합 오류를 가능한 빨리 감지합니다.

업데이트 : 나는이 이미지를 보냈는데 더 간단한 것을 찾을 수 없었습니다.

업데이트 2 : 마케팅 팀에서 피드백을 받음 (3 개의 질문이있는 시간) :

저는 실제로 3 가지 답변을 모두 좋아합니다 – 다른 이유로. 나는 그들 모두에게 감사하기 위해 로그인하고 싶다고 생각합니다!

분명히 그는 할 수 없습니다-그를 대신해 주셔서 감사합니다 :)

업데이트 3 : Wikipedia 기사 에 제목을 가져갈 때 꽤 좋은 원칙 이 포함되어 있음을 알았습니다 .

1. 코드 리포지토리 유지
2. 빌드 자동화
3. 빌드 자체 테스트 만들기
4. 모든 사람은 매일 기준을 준수합니다.
5. (기준선까지) 모든 커밋을 빌드해야합니다.
6. 빠른 빌드 유지
7. 프로덕션 환경의 복제본에서 테스트
8. 최신 결과물을 쉽게 얻을 수 있도록
9. 누구나 최신 빌드 결과를 볼 수 있습니다
10. 배포 자동화

누군가가 소프트웨어 제품을 구성하는 파일을 변경 한 후 체크인하려고하면 (즉, 변경 사항을 기본 제품 코드 에 통합 하려고 시도 ) 소프트웨어 제품이 여전히 성공적으로 빌드 될 수 있는지 확인하려고합니다.

일반적으로 CI 서버 라고하는 외부 시스템이 주기적으로 또는 모든 변경에 따라 버전 제어에서 소스 파일을 가져 와서 제품 빌드 (컴파일 / 테스트 / 패키지)를 시도합니다. CI 서버가 성공적으로 빌드를 수행 할 수 있으면 변경 사항이 성공적으로 통합 된 것입니다.

또한 CI 서버는 빌드가 실패하거나 성공한 경우 브로드 캐스트 할 수 있어야하므로 Jenkins (오늘 가장 많이 사용되는 CI 서버 중 하나)와 같은 시스템은 전자 메일 / 텍스트 및 대시 보드와 같은 웹 인터페이스를 보내는 방법을 갖습니다. 현재 및 과거 빌드, 코드를 체크인 한 사람, 문제가 발생했을 때 등에 대한 많은 정보 (위의 이미지에서 이는 피드백 메커니즘 입니다.)

CI는 지속적으로 작동하는 제품을 보장하기 때문에 중요합니다. 이는 소프트웨어 제품을 작업하는 모든 개발자와 QA와 같이 소프트웨어 제품의 일일 릴리스에 액세스하려는 모든 사람들에게 중요합니다.

마케팅 부서에서는 CI의 작동 방식 이 중요하지 않지만 CI가 소프트웨어의 새로운 릴리스에서 의미 하는 바 는 중요하지 않습니다 .

CI는 이상적으로 새로운 기능, 기능 또는 버그 수정을 추가하여 매일 출시 가능한 새로운 버전 의 소프트웨어를 고객에게 제시하거나 판매 할 준비가 된 것을 의미합니다. 그렇다고 매일 새 버전을 제공 해야하는 것은 아니지만 원하는 경우 가능합니다.

예를 들어, "2015"버전의 소프트웨어에 대해 공식적으로 출시 될 새로운 기능 세트가 있고 해당 기능 세트의 일부가 이미 코딩되어 통합 된 경우 마케팅 담당자는 현재 버전의 CI 없이는 팀원들에게 계획되지 않은 코드 동결을 요청해야했고 모든 팀원은 자신이 작업하는 반도 금 기능을 통합해야했습니다. 제품의 경우 자동 테스트가 충분히 준비되지 않았으며 회의에서 어떤 일이 발생할지 추측하십시오. 2015er 릴리스의 "알파 버전"은 특히 새로운 기능이 시연 될 때 충돌 위험이 훨씬 높습니다.

우리가 무엇을했는지 알지 않으면 CI가 무엇인지 알 수 없습니다. 세 부분으로 구성된 시스템을 상상해보십시오. 데이터를 수집하여 데이터베이스에 저장하는 UI가 있습니다. 데이터베이스에서 보고서를 작성하는보고 시스템이 있습니다. 그리고 데이터베이스를 모니터링하고 특정 기준이 충족되면 전자 메일 경고를 보내는 일종의 서버가 있습니다.

오래 전에 이것은 다음과 같이 작성되었습니다.

1. 데이터베이스 스키마 및 요구 사항에 동의합니다. 이유를 곧 알 수 있으므로 완벽해야했기 때문에 몇 주가 걸릴 것입니다.
2. 3 명의 개발자 또는 3 명의 독립적 인 개발자 팀을 3 개 조각에 할당
3. 각 개발자는 몇 주 또는 몇 달 동안 자신의 데이터베이스 복사본을 사용하여 작업을 수행하고 작업을 테스트합니다.

이 시간 동안 개발자는 서로의 코드를 실행하거나 다른 사람의 코드로 작성된 데이터베이스 버전을 사용하려고 시도하지 않았습니다. 보고서 작성자는 많은 양의 샘플 데이터를 직접 추가합니다. 경보 작성자는 보고서 이벤트를 시뮬레이트 한 레코드를 직접 추가합니다. 그리고 GUI 작성기는 데이터베이스를보고 GUI가 추가 한 것을 확인합니다. 시간이 지남에 따라 개발자는 인덱스를 지정하지 않거나 필드 길이가 너무 짧고 버전에서이를 수정하는 등의 방식으로 사양이 잘못되었음을 인식 할 것입니다. 그들은 행동 할 수있는 다른 사람들에게 말할 수도 있지만, 보통 이런 것들은 나중에 목록에 올 것입니다.

세 부분 모두가 완전히 코딩되고 개발자가 테스트하고 때로는 사용자가 테스트 (보고서, 화면 또는 전자 메일 경고 표시)하여 테스트하면 "통합"단계가됩니다. 이것은 종종 몇 달에 예산이 책정되었지만 여전히 지나갈 것입니다. dev 1에 의한 필드 길이 변경은 여기서 발견되며 개발자 2와 3은 코드를 크게 변경하고 UI를 변경해야합니다. 그 추가 지수는 그 자체로 혼란을 초래할 것입니다. 등등. 개발자 중 한 명이 사용자에게 필드를 추가하라는 지시를 받았지만 수행 한 경우 이제 다른 두 개도 추가해야했습니다.

이 단계는 잔인하게 고통스럽고 예측하기가 거의 불가능했습니다. 그래서 사람들은 "우리는 더 자주 통합해야한다"고 말하기 시작했습니다. "처음부터 함께 일해야합니다." "우리 중 한 명이 변경 요청을하면 (그런 식으로 얘기했듯이) 다른 사람들은 그것에 대해 알아야합니다." 일부 팀은 별도의 작업을 계속하면서 통합 테스트를 더 일찍 시작했습니다. 그리고 일부 팀은 처음부터 서로의 코드를 사용하고 항상 출력하기 시작했습니다. 그리고 그것은 지속적인 통합이되었습니다.

내가 그 첫 번째 이야기를 과장한다고 생각할 수도 있습니다. 나는 다음과 같은 결함이있는 코드를 확인하기 위해 연락을 취한 적이있는 회사에서 한 번 일했습니다.

• 그가 작업하지 않은 화면에는 아직 아무것도하지 않은 버튼이있었습니다.
• 화면 디자인에서 사인온 한 사용자가 없습니다 (정확한 색상 및 글꼴, 화면의 존재 여부, 기능 및 300 페이지 사양에있는 버튼).

그것이 완성 될 때까지 물건을 소스 컨트롤에 넣지 않는 것이 그의 의견이었습니다. 그는 일반적으로 1 년에 한두 번 체크인을했습니다. 우리는 약간의 철학 차이가있었습니다 :-)

또한 팀이 데이터베이스와 같은 공유 리소스와 연결이 끊어 졌다고 생각하기 어렵다면 실제로 동일한 접근법이 코드화되었다고 믿지 않을 것입니다. 내가 호출 할 수있는 함수를 작성 하시겠습니까? 훌륭합니다. 계속해서 그 동안 필요한 것을 하드 코딩하면됩니다. 몇 달 후 코드를 "통합"하여 API를 호출하고 null을 전달하면 코드가 터지는 것을 발견합니다. null을 반환하면 부풀려집니다. 나를 위해, 그것은 윤년과 다른 수천 가지를 다룰 수 없습니다. 독립적으로 작업 한 다음 통합 단계를 갖는 것이 정상입니다. 이제 광기처럼 들립니다.