인터프리터 언어에 CI를 어떻게 사용할 수 있습니까?

CI (Continuous Integration System)를 사용한 적이 없습니다. 나는 주로 MATLAB, Python 또는 PHP로 코딩합니다. 이들 중 어느 것도 빌드 단계가 없으며 CI가 내 작업에 어떻게 사용될 수 있는지 알지 못합니다. 대기업의 대형 프로젝트 친구가 언어는 중요하지 않다고 말했습니다.

빌드 단계가 없으면 CI가 어떻게 사용되는지 알 수 없습니다. CI를 단위 테스트를 실행할 테스트 환경이라고 생각할 수 있습니다. 뭔가 빠졌습니까?

용어로서의 지속적인 통합은 두 가지 별개의 아이디어를 의미합니다.

첫 번째는 워크 플로입니다. 팀의 모든 직원이 자체 지사에서 일한 후 몇 주 동안 프로그래밍 한 후 변경 사항을 기본으로 병합하려고하면 변경 사항이 거의 (가) 지속적으로 통합됩니다. 이로 인해 문제가 조기에 발생하고 호환되지 않는 변경이 방지됩니다. 그러나 변경 사항이 "작동"하는지 쉽게 확인할 수 있어야합니다.

이것은 두 번째 아이디어가 나오는 곳으로 훨씬 인기가 있습니다. CI 서버는 변경 사항을 가능한 빨리 테스트하는 깨끗한 환경입니다. 빌드를 재현 할 수 있도록 깨끗한 ​​환경이 필요합니다. 한 번 작동하면 항상 작동합니다. 이렇게하면 "하지만 컴퓨터에서 작동했습니다"문제를 피할 수 있습니다. 특히, CI 서버는 소프트웨어가 다른 시스템이나 다른 구성에서 실행될 때 모든 것이 작동하는지 확인해야합니다.

빌드 단계의 부족은 관련이 없습니다. 그러나 CI는 테스트 스위트가있는 경우에만 의미가 있습니다. 이 테스트 스위트는 자동이어야하며 실패가 없어야합니다. 테스트가 실패하면 적절한 개발자가 자신이 도입 한 문제를 해결할 수 있도록 알림을 받아야합니다 (컴파일로 빌드가없는 경우에도 "빌드 중단").

그러한 서버는 단순한 테스트 이상의 가치가 있다는 것이 밝혀졌습니다. 실제로, 대부분의 CI 소프트웨어는 다양한 구성으로 테스트를 실행하는 데는 열중하지만 모든 종류의 작업을 관리하는 데는 능숙합니다. 예를 들어 "연속적인"단위 테스트 외에도 야간 빌드로 전체 테스트를 수행 할 수 있습니다. 소프트웨어는 여러 Python 버전, 다른 라이브러리 버전으로 테스트 할 수 있습니다. 웹 사이트에서 사용 불능 링크가 있는지 테스트 할 수 있습니다. 코드를 통해 정적 분석, 스타일 검사기, 테스트 범위 도구 등을 실행할 수 있습니다. 문서를 생성 할 수 있습니다. 모든 테스트 스위트가 통과하면 패키징 프로세스가 시작되어 소프트웨어를 릴리스 할 수 있습니다. 이는 항상 배포 가능하고 데모 가능한 제품을 원하는 민첩한 설정에 유용합니다. 웹 앱의 등장으로 지속적인 배포 라는 아이디어도 있습니다: 모든 테스트를 통과하면 변경 사항을 프로덕션으로 자동 푸시 할 수 있습니다. 물론이를 위해서는 테스트 스위트에 대한 확신이 있어야합니다 (그렇지 않은 경우 더 큰 문제가 있음).

사실, 빌드를 수행하고 해당 빌드가 올바른지 확인하기 위해 CI 시스템이 특별히 필요하지는 않지만 이는 CI와 관련이 있습니다.

CI의 목적은 가능한 빨리 오류를 감지하는 것입니다. 일반적으로 말하면 오류가 조기에 발견 될수록 수정하는 비용이 저렴합니다. 이를 위해 빌드 단계가 필요하지 않은 경우에도 CI 시스템은 코드 분석 도구 사용, 테스트 환경으로의 배포, 자동화 할 수있는 단위 / 통합 / 회귀 / 기타 테스트 및 기타 단계를 자동화 할 수 있습니다. 오류를 확인하기 위해 자동으로 수행 할 수 있습니다.

지속적인 통합은 코드 컴파일 이상의 기능을 수행합니다. 그것이 전부라면, 우리는 그것을 위해 너무 많은 도구가 필요하지 않을 것입니다!

지속적인 통합 파이프 라인이 종종 수행한다고 생각하는 다른 작업들 :

• 자동 테스트 실행 (Python에는 풍부한 자동 테스트 라이브러리가 있으며 PHP에는 최소한 몇 가지가 있습니다. MATLAB과 대화 할 수 없습니다.)
• 배포 할 소프트웨어 번들링. 이 프로세스를 자동화하면 매번 정확하고 일관되며 반복 가능한 방식으로 수행됩니다. 어떤 단계도 잊혀지지 않을 것입니다. 이러한 배포 패키지를 생성하는 데 최대 한 번의 클릭이 걸립니다. (Python 앱을 휠로 번들링하는 것이 좋습니다.)
• 마일스톤 커밋에 태그를 지정합니다. 프로덕션 용 패키지를 작성할 때마다 태그를 지정하려고합니다.
• 자동 증분 버전 번호. 일반적으로 이것은 "빌드"번호 일뿐 더 의미있는 부분은 아니지만 특정 빌드를 고유하게 식별하는 것이 좋을 수 있습니다. 따라서 배치 된 위치를 알 수 있습니다.

엄격한 의미에서 "연속 통합"의 경계선으로 조금 더 나아가면 다음을 수행 할 수도 있습니다.

• 운영 체제 설정 및 종속성 설치를위한 자동화 된 프로세스가 있어야합니다.
• 소프트웨어 사본 자동 배포 (주로 패키지 관리자가 배포 한 웹 응용 프로그램 또는 소프트웨어에 유용) 실제로 일부 팀에서는이 기능을 사용하여 프로덕션 환경에 배포 (연속 전달)하지만 그렇지 않은 경우에도 프로덕션 이외의 코드 사본을 배포하는 데이 기능을 활용할 수 있습니다. 내가 일하는 일부 프로젝트의 경우 개발자가 코드를 QA에 제공하기 전에 코드를 테스트 할 수있는 사본, QA가 테스트 할 수있는 사본, 데모 목적으로보다 "안정적인"사본이 있습니다.

요점은 바로 이것입니다. 코드를 작성하는 것 외에도 소프트웨어를 개발하는 과정에서 정기적으로 수행해야하는 작업이 있습니다. 이러한 작업을 자동화하고 서버에서 실행하면

• 일관된 프로세스 (Stan과 Sally가 다른 방식으로 작업을 수행하지 않음)
• 코드로 기록 된 프로세스에 대한 지식 (스크립트를 읽을 수있는 사람이라면 누구나 Sally가 프로세스를 수행하거나 방법을 아는 사람이 아니라 배포와 관련된 단계를 배울 수 있습니다.)
• 프로세스 복제 간소화 (웹 사이트의 여러 복사본을 간단하게 배포 : 새로운 구성 만 제공)
• 보다 철저한 테스트 (Bob은 자신의 페이지 만 테스트했지만 변경 사항으로 인해 Sally의 페이지가 깨졌습니다. Sally는 파일 커밋을 잊었습니다. Stan은 앱과 함께 설치해야하는 새로운 종속성을 추가했지만 IDE에 의해 자동으로 설치되기 때문에이를 인식하지 못했습니다. 나는 이것들을 모두 어떤 형태로 보았습니다.)

그리고 아마도 마음에 들지 않는 다른 이점들도 있습니다.

솔루션을 컴파일 할 필요는 없지만 CI는 구성 파일 / 폴더 경로 등을 변경하고 팀에있는 경우 prod 상태에 대한 변경을 승격시키고 배포하여 도움을 줄 수 있습니다.

5 개의 서로 다른 QA 서버에 Python 코드를 배포하고 다른 QA 데이터베이스를 가리키는 다음 자동화 된 테스트 실행 (CI에 의해 트리거 된)을 수행하면 빌드가 프로덕션으로 승격되고 모든 프로덕션 서버에 대해 적절한 구성 변경 사항으로 배포됩니다 .