지속적인 통합 및 Jenkins CI 서버에 대한 주요 지침

키 포인트

CI (Continuous Integration) 및 Jenkins CI Server는 최신 소프트웨어 개발에 없어서는 안될 도구이며, 이는 팀이 반복 프로세스를 자동화하여 고품질 소프트웨어를 출시하고 시간을 절약 할 수 있도록 도와줍니다. CI는 테스트 자동화를 강조하여 테스트 엔지니어가 탐색 테스트 및 에지 케이스에 집중할 수있게하면서 개발자 제출 후 몇 분 안에 특정 지점에서 각 커밋의 품질을 보장 ​​할 수 있습니다.

Jenkins CI Server는 기존 플러그인 또는 새 플러그인을 만들어 사용자 정의 할 수있는 오픈 소스 CI 도구입니다. 여러 기계에 작업을 할당하고 Python을 포함한 다양한 언어로 프로젝트의 지속적인 통합을 처리하여 병렬 건물을 지원합니다.

Jenkins는 더 많은 설정 및 유지 보수가 필요하지만 유연성 및 제어 가능성 및 무료 오픈 소스 기능은 다른 CI 서버보다 강력한 선택이됩니다. 또한 다양한 버전 제어 시스템과 잘 통합되어 다른 프로젝트를위한 보편적 인 도구입니다.
이 기사는 원래 TestProject -Test Automation Blog 에 게시되었습니다. 다음은 소프트웨어 개발의 필수 관행 인 CI (Continuous Integration)와 업계 표준 오픈 소스 연속 통합 도구 인 Jenkins를 자세히 소개합니다. 지속적인 통합 및 Jenkins CI 서버를 구현하면 Jenkins 배포가 개발 팀이 고품질 소프트웨어를 출시하고 귀중한 시간을 절약하는 데 도움이되는 방법을 배우게됩니다.
Jenkins 및 지속적인 통합에 대해 더 배우고 싶습니까? 다음 링크를 확인하십시오 :
• <:> 화면 녹화 : 어떤 연속 통합 도구가 비트 버킷을 지원합니까?
Jenkins에서 PHP 프로젝트를 준비하고 구축하십시오 Jenkins와의 지속적인 통합

재 도입 Jenkins : 파이프 라인을 사용한 자동 테스트

설치 및 보호 젠킨스

최신 소프트웨어 개발 관행에는 가능한 빨리 또는 생산 환경에서 완전 기능적인 소프트웨어를 배포해야합니다. 예를 들어, 민첩한 접근 방식은 팀이 작은 단위로 작업하고 각 스프린트 후 생산 환경에 배치 하여이 동작을 직접 강화합니다 (읽기 : 민첩한 프로젝트를위한 테스트 자동화 전략). 개발 팀은 소프트웨어를 개발 한 다음 QA, UAT 및 모든 생산 라인에 더 이상 존재하지 않는 데 몇 달을 보냈습니다. 오늘날에는 완전히 기능적인 소프트웨어를 보유하고 있으며 릴리스주기가 끝날 때 중요한 소프트웨어 변경을 도입하는 등 소프트웨어 품질을 위험에 빠뜨리는 상황을 허용하지 않습니다. 이것은 지속적인 통합이 시작되는 곳입니다. CI는 무엇입니까?

CI는 테스트 된 코드를 안정적인 프로젝트 분야에 자주 통합 할 수 있도록 전략을 강화하는 관행입니다. 특히 "테스트 된 코드"를 강조하고 싶습니다. 이는 별도의 분기에서 개발 된 기능도 테스트되어 안정적인 지점에 통합되어 있음을 의미합니다.

누가 CI를하고 있습니까?

일반적으로 DevOps 엔지니어는 일반적으로 CI 파이프 라인 설정을 담당합니다. 오늘날 DevOps 엔지니어의 역할은 프로세스와 소프트웨어 품질을 보장하기 때문에 테스트 엔지니어의 역할과 매우 유사합니다. 나는 보통 QA와 생산이 고객과 가장 가까운 교차로라고 말합니다. 이런 의미에서 CI는 테스트 엔지니어에게 다음과 같은 영역에 적극적으로 참여하여 전반적인 프로세스 및 소프트웨어 품질을 향상시키는 매우 강력한 도구를 제공합니다.

<:> 테스트 자동화 : 몇 년 전 사람들은 수동 테스트 및 자동 테스트에 대해 논의했습니다. CI를 사용하면 테스트 자동화는 필수 불가능 해져서 궁극적으로 다른 테스트 작업에 중점을 둔 소중한 시간을 많이 절약 할 수 있습니다. 또한 수동 테스트 및 자동화 된 테스트는 상호 배타적 일 수 없다는 점도 언급 할 가치가 있습니다.

테스트 보고서 : CI의 테스트 보고서의 경우 기존보고 솔루션을 사용하거나 자체보고 모듈을 구축 할 수 있습니다. 두 경우 모두, 이것은 모든 빌드 실행에 응용 프로그램 코드가 얼마나 잘 있는지 명확하게 보여줍니다. 모든 개발 팀원 이이 정보에 액세스 할 수 있으며 코드의 품질을 향상시키기 위해 계속 노력하는 것이 중요합니다.

배포 프로세스 : 테스트 엔지니어는 응용 프로그램의 배포 프로세스에 더 많이 관여하며 사용 된 테스트 자동화 도구 또는 프레임 워크의 내부 아키텍처에 대한 추가 정보를 제공합니다. 이 지식은 특히 "숨겨진"응용 프로그램 문제를 식별 할 때 매우 중요합니다.

• ci
의 이점
• CI는 테스트 자동화를 강조하여 테스트 엔지니어가 탐색 테스트, 에지 케이스 테스트 및 새로운 테스트 방법에 집중할 수 있도록합니다.
특정 지점에서 특정 커밋의 품질은 개발자 제출 후 몇 분 안에 나타납니다.
• 코드가 지점에서 테스트 된 후 안정적인 분기에 통합하는 것이 매우 신중합니다 (CI 프로세스는이 작업을 실행해야합니다). 응용 프로그램 배포는 반복 된 명령없이 올바르게 설정되면 자동으로 실행됩니다.
이러한 모든 혜택은 팀 관점에서 기하 급수적으로 증가합니다.

일반적인 CI 시나리오 개발 팀에는 프로젝트가 포함 된 자체 소스 코드 버전 제어 저장소가 있습니다 (일반적으로 Github). 안정적인 지점 (메인 브랜치)은 종종 작업 지점으로 간주되며 메인 브랜치에서 직접 새로운 기능을 거의 개발하지 않습니다. 대신 개발자는 새로운 기능을 개발하기 위해 자체 지점을 만듭니다 (지체 A의 지점 A). 변경 사항이 해당 지점의 저장소로 푸시되고 개발자가 풀 요청을 수행하면 해당 분기에 대해 일부 기본 테스트 세트 (연기 테스트)를 수행해야합니다. CI 관점에서 이것은 일반적으로 다음을 의미합니다.

CI 프로세스가 완료되면 테스트 엔지니어 및 개발자의 관점에서 몇 가지 요구 사항이 있습니다.
테스터 : 분기 a의 함수를 다시
• 개발자 : 다른 개발자는 코드가 충분한 품질인지 확인하기 위해 피어 코드 리뷰를 수행합니다. 개발자 : 코드를 메인 브랜치로 수동으로 병합하고 병합 충돌을 해결합니다 (발생하는 경우).
• 연기 테스트는 코드 리뷰를 받고있는 개발자와 풀 요청 브랜치에서 기능을 재개 해야하는 테스트 엔지니어에게 많은 시간을 절약합니다. 풀 요청의 연기 테스트가 실패하면 기능 A를 담당하는 개발자는 이제 연기 테스트 기능을 수정하고 새로운 풀 요청을 발행 할 책임이 있습니다 (문제가 해결 될 때까지 문제가있는 코드는 기본 분기에 병합되지 않습니다. ).
이 작업이 완료되고 기능 A에 대한 새 코드가 CI의 관점에서 메인 브랜치로 병합되면 다음이 발생합니다.
이것은 병합이 성공했으며 연기 테스트 기능이 여전히 유효했음을 나타냅니다. 이제 테스트 엔지니어가 메인 브랜치에서 기능을 다시 테스트하는 것이 책임입니다 (병합에 부작용이 없도록하기 위해 기능 a). 물론 대부분의 기능을 다루기 위해 시간이 지남에 따라 테스트 자동화 제품군을 향상시키는 것은 좋은 습관입니다.
테스트 엔지니어가 더 많은 작업 (현재 기능 테스트 및 이전 기능 테스트)을 가지고 있기 때문에 프로젝트의 늦은 반복에서 점점 더 중요 해지고 있습니다. CI 관점에서 회귀 테스트는 일반적으로 회귀 테스트의 실행이 일반적으로 테스트 엔지니어가 회귀 테스트를 명시 적으로 실행하거나 스케줄러를 사용할 때 (예 : 매일 밤 회귀 테스트 수행) 발생할 때 발생합니다. 이 작업을 사용자 정의하는 것은 좋은 습관입니다. 따라서이 작업을 수행 할 지점을 지정할 수 있습니다 (여기에서 회귀 테스트 자동화를 수행 할 이유와시기에 대한 자세한 내용). 프로세스는 다음과 같습니다.

Jenkins 도구 소개 Jenkins Ci 서버 용어 숙제 : Jenkins 용어에서 가장 중요한 "단위"는 숙제입니다. 작업은 Jenkins CI 서버의 단일 실행 장치이며 특정 결과 (Pass/Fail)가 있어야합니다. 예 : 작업은 배치 작업, 연기 테스트 작업, 회귀 테스트 작업 등이 될 수 있습니다. 작업은 순서대로 실행되는 여러 영역으로 구성되며, 다음 단락에서 설명됩니다. Jenkins 작업의 구조.

플러그인 : Jenkins 테스트 자동화의 주요 기능 중 하나는 기존 플러그인을 사용하거나 고유 한 플러그인을 만들어 사용자 정의 할 수 있다는 것입니다. 작업 구성 섹션에서 Jenkins 구성 섹션에 이르기까지 Jenkins 도구의 모든 것은 실제로 플러그인입니다. Jenkins 커뮤니티의 큰 규모로 인해 가장 까다로운 CI 워크 플로 작업의 요구를 충족시키기 위해 다양한 Jenkins 플러그인이 이미 존재합니다. 즉, 사용자 정의 솔루션을 만드는 대신 유용한 플러그인을 발견 할 수 있습니다. 노드 : 가장 간단한 설정에서 Jenkins 인스턴스는 모든 작업이 실행되는 기계에서 실행됩니다. 소규모 테스트와 소량의 과제의 경우 이는 의미가 있습니다. 그러나 실제로 여러 팀이 동일한 Jenkins 인스턴스를 사용하는 경우가 종종 있습니다. 그들은 많은 일자리를 가지고 있기 때문에 보안, 재해 회복, 성능, 확장 성 등과 같은 이유로 인스턴스에서 실행하는 것이 좋지 않습니다.

Jenkins에 Mas 이런 식으로 Jenkins 호스트는 많이 사용되지 않으며 팀에는 테스트 자동화 프로젝트에 가장 적합한 자체 슬레이브 머신이 있습니다. 또한 슬레이브 노드는 실행될 몇 가지 병렬 작업 (노드 당 실행자 수)을 처리하도록 구성됩니다. AWS에서 주문형 노드를 구성 할 수도 있습니다. 이것은 노드가 작업을 실행해야 할 때만 존재한다는 것을 의미합니다. 이것은 회귀 테스트를 실행할 때만 완전히 활용 될 더 큰 기계를 원하기 때문에 매우 유용합니다. 이 경우 작업이 실행되고 완료되면 (구성 유휴 시간에 따라) AWS에서 더 큰 EC2 인스턴스가 시작됩니다 (구성 유휴 시간에 따라) 인스턴스는 일정 기간 동안 계속 활성화됩니다. 그 후, AWS 서비스와 같은 시간당 유료 서비스를 사용할 때 어떤 접근 방식이 더 유리한지를 결정합니다.

Jenkins Job의 구조 Jenkins CI 서버에서 각 Jenkins 작업에는 여러 부분이 포함됩니다.
일반 : 여기서는 프로젝트/작업 이름/설명을 지정하고 필요에 따라 작업 매개 변수 추가, 작업 로그 회전 전략 정의 등을 지정합니다. 다음 화면은 로그 회전을 구성하는 방법을 보여줍니다 (빌드 로그를 유지하는 일의 수 또는 보관할 마지막 빌드 로그 수를 지정할 수 있음) 그러나 0.0.1,이 값은 작업을 시작할 때 지정할 수 있으며이 작업이 실행되는 위치를 구성하는 방법 (슬레이브 노드 이름) :

• Jenkins 소스 코드 관리 : 이름에서 알 수 있듯이 Jenkins CI 서버에서 소스 코드 리포지토리 (예 : Github 또는 Subversion)를 정의합니다.

  

  Jenkins 빌드 트리거 : 작업 실행 시간을 예약하십시오 (주기적으로 다른 작업 후에 Github 풀 요청이 발생할 때 변경 사항이 GitHub 등으로 밀려 나면).

  

• Jenkins 빌드 환경 : 여기서는 빌드가 실행되는 환경과 관련된 옵션을 정의합니다 (작업이 실행될 때마다 작업 영역을 삭제하고 일정 기간 동안 일정 중단 된 경우 작업을 중단합니다 ... 등).

  

  Jenkins 빌드 : Jenkins CI 서버에서는 이것이 각 작업에서 가장 중요한 단계입니다. 이 단계의 결과는 실행 종료시 작업 상태에 영향을 미칩니다. 설치된 플러그인에 따라 많은 옵션을 사용할 수 있으며 가장 일반적으로 사용되는 플러그인은 다음과 같습니다. 쉘 실행, 그루비 스크립트 실행, Ant/Maven/Gradle 스크립트 호출, Windows 배치 명령 실행 등

• 이것은 자주 사용되는 "Execute Shell"플러그인의 예입니다. 자신의 쉘 스크립트를 인화하거나 기존 쉘 스크립트를 실행할 수 있습니다.

  Jenkins 구축 후 작업 :이 작업 의이 부분은 작업 결과를보고하거나 Jenkins 파이프 라인에서 다른 작업을 호출하는 데 사용됩니다. 일반적으로, 우리는 작업의 실행 상태가 포함 된 이메일을 보내고, HTML 보고서를 게시하고, 주니트 결과, 빌드 스테이지에 내장 된 아티팩트를 S3 등으로 게시 할 수 있습니다.

  이메일 제목 줄에 $ build_id가 어떻게 지정되는지 확인하십시오. 이 작업은 매개 변수화되므로 작업이 시작될 때이 값이 지정됩니다. 이 매개 변수는 작업의 Jenkins 빌드 및 구축 후 작업 섹션에서 사용할 수 있습니다.

• 결론 지금까지 Jenkins CI 서버의 주요 이점과 CI 자체가 소프트웨어 개발 프로세스 및 테스트 엔지니어에 어떻게 추가되는지 배웠습니다. 다른 기술과 마찬가지로 기본 사항을 습득하고 장점을 경험하는 데 시간이 걸립니다. CI에 시간을 투자하는 것이 좋습니다. 이는 장기적으로 가치가 있습니다. 특히 Jenkins CI 서버가 적용되면 많은 고통스럽고 반복적 인 프로세스가 자동화되며 갑자기 제품 개선에 집중할 시간이 더 있습니다.

  팀도 지속적인 통합 및 Jenkins CI 서버를 구현 했습니까? 팀의 경험을 자유롭게 공유하고 의견에 질문하십시오!

  이 기사는 원래 TestProject -Test Automation Blog 에 게시되었습니다.Jenkins CI 서버와의 지속적인 통합 FAQ
  Jenkins와 Travis CI의 주요 차이점은 무엇입니까?

  Jenkins와 Travis Ci는 모두 인기있는 연속 통합 도구이지만 몇 가지 주요 차이점이 있습니다. Jenkins는 자체 호스팅 솔루션으로 자신의 서버를 관리하고 유지 관리해야합니다. 사용자 정의가 가능하며 거의 모든 CI/CD 워크 플로를 수용하도록 구성 할 수 있습니다. 반면에 Travis CI는 설정 및 사용이 쉬운 클라우드 기반 서비스입니다. 그것은 Github와 잘 통합되며 많은 언어를 상자에서 지원합니다. 그러나 복잡한 워크 플로의 경우 젠킨스만큼 유연하지 않을 수 있습니다.

  Jenkins는 Gitlab Ci/CD와 어떻게 비교됩니까?

  Jenkins와 Gitlab Ci/CD는 모두 강력한 연속 통합 솔루션을 제공합니다. Jenkins는 유연성과 큰 플러그인 생태계로 유명하며 Gitlab CI/CD는 Gitlab 생태계와의 원활한 통합에 대한 찬사를 받았습니다. Gitlab CI/CD는 또한 내장 Docker 지원을 제공하며 Docker를 사용하는 팀에게는 큰 이점이 될 수 있습니다.

  다른 CI 서버 대신 Jenkins를 사용하면 어떤 장점이 있습니까?

  Jenkins는 다른 CI 서버에 비해 몇 가지 장점을 제공합니다. 오픈 소스이며 크고 활발한 커뮤니티가 있으며 끊임없이 개선되고 업데이트되고 있음을 의미합니다. 또한 특정 요구에 맞게 기능을 확장 할 수있는 막대한 플러그인 생태계가 있습니다. 또한 Jenkins는 다양한 언어와 도구를 지원하므로 다양한 프로젝트에서 공통적 인 선택이됩니다.

  Jenkins는 Python Projects의 지속적인 통합을 어떻게 처리합니까?

  Jenkins는 Python 프로젝트의 지속적인 통합을 처리하는 보편적 인 도구입니다. Python 응용 프로그램의 구성, 테스트 및 배포를 자동화하고 많은 인기있는 Python 테스트 프레임 워크를 지원합니다. Jenkins는 또한 GIT와 같은 버전 제어 시스템과 잘 통합되어 기존 워크 플로에 쉽게 통합 할 수 있습니다.

  Jenkins와 Travis CI 중에서 선택할 때 주요 고려 사항은 무엇입니까?

  Jenkins와 Travis CI 중에서 선택할 때 팀의 기술 전문 지식, CI/CD 워크 플로우의 복잡성 및 예산과 같은 요소를 고려해야합니다. Jenkins는 더 많은 설정 및 유지 보수가 필요하지만 유연성과 제어력이 향상됩니다. Travis CI는 설정 및 사용이 쉽지만 복잡한 워크 플로우에는 유연하지 않을 수 있습니다. 또한 유료 서비스이며 Jenkins는 무료이며 오픈 소스입니다.

  Jenkins는 CI/CD 파이프 라인을 어떻게 지원합니까?

  Jenkins는 모든 단계의 코드 전달 단계를 자동화하여 통합 및 테스트에서 배포까지 CI/CD 파이프 라인을 지원합니다. 개발자가 코드에서 문제를 신속하게 식별하고 수정할 수 있으므로 지속적인 피드백이 가능합니다. Jenkins는 또한 CI/CD 생태계의 다양한 도구와 통합되어 CI/CD 파이프 라인을 구현하기위한 일반적인 선택입니다.

  jenkins는 Github에서 호스팅되지 않은 프로젝트에 사용될 수 있습니까?

  예, Jenkins는 Github에서 호스팅되지 않은 프로젝트에 사용할 수 있습니다. 전복, 수은 및 성능을 포함한 다양한 버전 제어 시스템을 지원합니다. 이로 인해 Jenkins는 다른 버전 제어 시스템을 사용하는 팀에게 보편적 인 선택이됩니다.

  Jenkins는 병렬 빌드를 어떻게 처리합니까?

  Jenkins는 여러 기계 나 집행자간에 작업을 할당하여 병렬 빌드를 처리합니다. 이를 통해 더 빠른 빌드 시간과보다 효율적인 리소스 활용도가 가능합니다. 빌드 인프라를 자동으로 관리하도록 Jenkins를 구성하거나 어떤 기계에서 실행 해야하는 작업을 수동으로 지정할 수 있습니다.

  Jenkins를 설정할 때 발생하는 일반적인 도전은 무엇입니까?

  Jenkins를 설정할 때 일반적인 과제에는 종속성 관리, 빌드 트리거 구성 및 안전한 액세스 설정이 포함됩니다. 그러나 Jenkins에는 크고 활발한 커뮤니티가 있으므로 이러한 과제를 극복하는 데 도움이되는 많은 자원이 있습니다.

  Jenkins의 기능을 확장하는 방법은 무엇입니까?

  플러그인을 설치하여 Jenkins의 기능을 확장 할 수 있습니다. Jenkins는 다양한 버전 제어 시스템과의 통합에서 향상된 사용자 인터페이스에 이르기까지 다양한 기능을위한 플러그인을 포함하는 막대한 플러그인 생태계를 보유하고 있습니다. 기존 플러그인에서 제공하지 않은 기능이 필요한 경우 고유 한 플러그인을 작성할 수도 있습니다.

위 내용은 지속적인 통합 및 Jenkins CI 서버에 대한 주요 지침의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!