Jenkins란 무엇이며 왜 사용해야 할까요?

많은 devops팀의 일반적인 문제는 조각난 워크 플로우입니다. 대부분 비효율적인 업무에 화를 내게 되고는 합니다.

팀원은 독립적으로 일하는 경향이 있습니다. 솔로 코딩을 통해 엔지니어는 정기적으로 버전 제어 외부에서 많은 양의 코드를 생성합니다. 개발자가 "완료"되면 작업을 베이스 코드에 추가합니다. 그런 다음 다른 팀이 수동으로 테스트를 실행하여 빌드를 확인합니다.

수년 동안 많은 팀이 이러한 노동 분업이 성 가시고 문제가 있음을 발견했습니다.

여러 개발자가 개별적으로 버전 제어를 크게 변경하면 복잡한 버그가 발생하고 시간이 많이 걸리는 수정 사항이 증가하며 더 많은 수동 테스트를 수행하는 데 걸리는 시간이 늘어납니다. 모든 것이 느려집니다.

이렇게 하면 지루한 디버깅으로 빌드 주기가 단축되고 생산 시간이 단축되고 궁극적으로 회사의 수익이 저하됩니다.

지속적인 통합이란 무엇을 의미할까요?

CI (Continuous Integration)는 개발자가 공유 버전 제어 저장소에서 팀의 코드를 컴파일 할 수 있도록함으로써 빌드주기 비 효율성을 줄이기 위한 프로세스입니다. CI를 사용하면 테스트를 자동화할 수 있으므로 예를 들어 단위 테스트 또는 통합 테스트를 자동으로 실행하도록 시스템을 설정할 수 있습니다.

CI는 각 엔지니어의 커밋을 자동으로 모니터링합니다. 이렇게하면 코드 작성 및 검증이 간소화되어 테스트가 큰 관심을 끌지 않습니다. 소프트웨어 개발 커뮤니티에서 모범 사례로 인식됩니다.

CI는 가시성을 높이는 공유 서버에서 실행되므로 프로젝트의 모든 엔지니어는 매일 매일 기본 코드의 변경 사항을 알 수 있습니다. 또한 개발자가 실패한 코드를 제출할 때 경고하여 서버 오류를 수정할 수 있도록 서버를 구성 할 수 있습니다.

CI 자동화를 사용하면 개발 릴리스 주기를 단축하고 제품 품질을 향상시킬 수 있습니다. CI는 본질적으로 팀이 기계를 사용하여 최선을 다할 수 있게 해주므로 사람은 회사에 더 많은 가치를 가져다 줄 수 있습니다. 또한 프로젝트와 요구에 맞게 모두 사용자 정의 할 수 있습니다.

CI 환경은 다양한 수준의 테스트 자동화를 제공 할 수 있습니다.

Jenkins를 포함한 CI / CD 서버를 사용하면 팀이 실행해야 하는 테스트를 설정할 수 있습니다.

구현할 수 있는 다양한 수준의 테스트가 있습니다. 가장 기본적인 테스트는 코드가 실제로 컴파일되는지 여부입니다. 코드는 “린트”하거나 스타일을 검사 할 수도 있습니다. 팀은 단위, 통합, 스트레스, 회귀 테스트 등을 비롯하여 다른 기반을 포괄하는 더 복잡한 테스트를 작성할 수 있습니다.

Continuous Integration은 Continuous Delivery와 어떻게 다를까요?

CI 서비스는 전체 응용 프로그램을 컴파일하고 테스트합니다. 또한 지속적인 딜리버리는 이 테스팅 된 애플리케이션을 예를 들어 알파 테스터가 조기 피드백을 사용하고 제공 할 수 있도록 저장소로 푸시합니다. CD 빌드는 프로덕션 환경에 자동으로 배포되며 광범위한 베타 테스트에도 사용할 수 있습니다.

CD는 린 로지스틱스를 목표로 합니다. 새 코드 추가부터 승인 테스트까지 프로세스를 자동화합니다. CD는 모든 단계를 자동화하여 빌드를 배포 할 준비가 되었습니다.

지속적인 딜리버리 : 응용 프로그램을 구축하고 테스트를 실행하는 것 외에도 응용 프로그램은 "전달"되기도합니다. 이는 종종 누군가가 수동 테스트를 수행 할 수 있도록 서버에 배치하거나 테스트 그룹의 사용자에게 전자 메일로 전송하는 것을 의미합니다.

프로덕션 빌드의 경우 딜리버리란 최종 사용자를 위한 애플리케이션 배포를 의미합니다. 이를 통해 제품을 보다 빠르고 소규모로 배포 할 수있어 배포 위험이 줄어 듭니다. 정기적으로 작고 간결한 배송은 일년에 한 두번만 발생하는 큰 배송보다 덜 위험합니다.

Continuous Integration / Delivery는 개발 팀에 어떤 도움을 줄까요?

많은 사람들이 위에서 언급 한 이유로 모든 커밋에서 자동으로 모든 코드를 확인하고 정기적으로 테스트를 실행하고 지속적으로 배포하는 것이 모범 사례로 간주되므로 CI에 대해 이야기합니다.

프로세스는 각 개발자의 기여가 함께 잘 작동하는지 확인합니다. 이러한 문제를 조기에 발견하면 버그를 보다 쉽고 빠르게 수정할 수 있습니다.

짐작할 수 있듯이 CI / CD를 구현하면 팀에 문화적 변화가 일어납니다. 보다 민첩하고 통합되어집니다.

CI는 팀이 충돌하는 새로운 코드 세그먼트를 수동으로 해결하거나 빌드를 트리거하거나 테스트를 실행하는 데 시간을 낭비하지 않도록 하기 위해 만들어졌습니다. 대신 코드에 작은 점진적 변경을 추가하여 해결하기 위해 거대하고 복잡한 버그가 발생하지 않도록 권장합니다. 따라서 빌드주기가 빨라져 배포 및 프로덕션이 능률화 될 수 있습니다.

또한 생산은 비즈니스에서 실제로 돈을 버는 곳입니다.

또한 흥미롭게도 다중 개발자 원격 팀의 경우 CI는 지리적 위치에 관계없이 모든 작업을한데 모아 지속적으로 결합하여 작업을 모두 동일하게 유지하므로 구현하는 데 매우 유용합니다.

Jenkins를 실행하면 코드가 컴파일되는지 지속적으로 확인하고 모든 커밋 후에 기본 코드를 확인하도록 프로그래밍한 기본 테스트 세트를 실행할 수 있습니다.

병합된 코드를 통합 환경에 자동으로 배포하여 수동 테스트에 사용할 수 있습니다.

또한, 이를 사용하여 프로덕션 빌드를 생성 및 배포합니다. 단일 시스템을 업데이트하지 않기 때문에 배포가 복잡합니다. 전체 시스템 클러스터를 업데이트하고 있습니다. 서비스를 방해하지 않는 방식으로 업데이트를 수행해야합니다. 이러한 환경에 배포하면 사람이 수행하면 오류가 발생할 수 있습니다

젠킨스 소개

Jenkins는 Java로 작성된 CI 서버의 오픈 소스 구현으로, 프로젝트의 빌드주기를 자동화하는 자체 호스팅 옵션으로 사용할 수 있습니다. 모든 프로그래밍 언어 및 Windows, Linux 및 macOS를 포함한 여러 플랫폼에서 작동합니다.

원래 "Hudson"으로 2006년에 설립 된 Jenkins는 최고의 자동화 서버 중 하나입니다. 확장 가능한 플러그인 기반 아키텍처 개발자를 사용하여 Jenkins를 다양한 빌드, 테스트 및 배포 자동화 워크로드에 적용하기 위해 수백 개의 플러그인을 만들었습니다. 2015년 Jenkins는 알려진 설치 수가 100,000 개를 넘어서 가장 널리 배포 된 자동화 서버입니다.

Jenkins의 주요 이점 중 하나는 많은 커뮤니티 지원을 제공하는 잘 알려진 도구이며 사용 가능한 많은 플러그인 (Slack, GitHub, Docker, Build Pipeline 등)을 포함하여 많은 플러그인이 있으며 대규모 개발자 커뮤니티에서 잘 관리하고 있습니다.

CI / CD와 Jenkins 프로젝트에 관한 많은 이야기가 있습니다. 그러나 2017년 말까지 CI 환경을 운영하는 데 많은 시간과 비용이 소요되는 경우가 많기 때문에 놀라운 수의 팀이 시스템을 사용하거나 유지 관리하지 않습니다.

젠킨스의 장점과 단점

Jenkins는 친숙하지 않은 사용자 인터페이스를 갖춘 오래된 도구입니다.

좋은 소식은 Jenkins 프로젝트가 UI를 크게 향상시키기 위한 지속적인 제공 소프트웨어인 Blue Ocean을 방금 발표했다는 것입니다. 100 % 오픈 소스입니다.

팀에서 지속적인 통합 옵션을 고려할 때 Jenkins는 서버에서 실행해야 하며 (비용) 시스템 관리 기술 (시간)을 가진 사람의 관심이 필요한 경우가 있습니다. 시스템을 설정한 다음 자체적으로 실행되기를 기대할 수 없으며 시스템을 자주 업데이트하고 유지 관리해야합니다.

그러나 Jenkins는 오픈 소스이며 개발자 팀을 위해 CI / CD를 구현할 수 있는 가장 널리 사용되고 가장 많이 사용되는 무료 도구 중 하나입니다.

대부분의 팀의 진입 장벽은 초기 설정, 지연 또는 이전 설정 시도 실패입니다. 사람들은 이것이 최선의 방법이라는 것을 알고 있지만 많은 팀은 보다 긴급한 코딩 작업을 위해 이를 무시합니다. 아마도 팀의 누군가가 어느 시점에서 Jenkins를 구현하려고 시도했지만 성공적으로 유지하지 못했습니다. 어쩌면 낭비한 노력으로 상사가 나쁜 인상을 받았을 수도 있습니다.

사람들이 CI 서버를 구현하지 않는 이유는 대개 매우 실용적입니다.

한 가지 주요 이유 : CI 시스템이 정기적으로 중단됩니다. 프로젝트의 설정이 변경되면 종종 CI 시스템의 구성을 다시 조정해야합니다. CI 시스템이 팀에 의해 가치가 높은 것으로 인식되지 않으면 CI 시스템을 옆으로 치우는 경향이 있으므로 가치 제공이 중단됩니다.

CI를 사용하지 않는 또 다른 이유는 테스트를 작성해야 하기 때문입니다. 유닛 테스트는 대부분의 개발자가 하고 싶은 일 (예 : 모범 사례)이지만 할 시간을 찾지 못하는 경우가 많습니다. 당연히 실제 소프트웨어를 코딩하는 것이 더 많은 관리 작업보다 비즈니스 우선 순위가 높습니다.

또한 테스트가 중단되므로 테스트중인 기능이 변경되면 업데이트 해야 합니다. 업데이트 되지 않으면 위와 같이 가치 제공이 중단됩니다. 인프라 유지 관리 우선 순위를 지정해야 합니다. 그렇지 않으면 작동하지 않습니다.

요약하면, 설정하는 데 시간이 걸리고 업데이트를 유지하려면 상당한 양의 작업이 필요합니다. 그러나 팀은 시스템 유지 관리를 간소화하고 효율성을 높이기 위해 테스트할 수 있습니다.

물론 Jenkins에 대한 SaaS 대안이 호스팅되어 있으므로 다른 사람이 소프트웨어를 유지 관리하기 위해 약간의 추가 비용을 지불 할 경우 도움이 될 수 있습니다. 기업은 Jenkins가 제공하는 것보다 우수한 UI가 필요할 때 이 옵션을 선택하는 경향이 있습니다. 그러나 자체 호스팅의 주요 이점은 자신의 데이터 보안을 보다 강력하게 제어 할 수 있다는 것입니다.

CI를 구현하려면 특히 경영진의 문화적 변화가 필요합니다. 그들은 이 "비생산적인 것들"이 이루어질 수 있는 시간을 허용해야하지만, 다른 일상적인 작업들도 보류됩니다.

그럼에도 불구하고 짧은 시간의 희생은 회사 전체의 장기적인 이익으로 해석됩니다. Jenkins를 사용하면 코드를 유지 관리하기가 더 쉬워지고 버그가 줄어 듭니다. 팀이 더욱 통합되고 구축 시간이 단축됩니다. 비즈니스는 더 빨리 배포하고 고객의 변화하는 요구에 부응할 수 있습니다.

이 모든 것은 사고 방식 전환이 필요합니다.

CI는 비용이 아니라 투자입니다. 구현을 위한 ROI는 시간 절약, 오류 방지 및 고객에게 보다 쉽게 ​​제공되는 고품질 제품으로 생산될 수 있습니다.