Jenkins가 DevOps의 엔진이되는 이유

애자일 개발, DevOps, 지속적인 통합과 같은 추세는 소프트웨어를 매우 효율적으로 구축하고 필요한 경우 한푼도 켜야하는 현대 기업의 요구를 나타냅니다.

후자의 행동은 CloudBees가 오늘날의 회사가 된 방법입니다. 한때 Java 코더를위한 독립적 인 퍼블릭 클라우드 PaaS 제공 업체 ( '어떤 PaaS를 사용해야하나요?'에서 Andrew Oliver가 높게 평가), CloudBees는 18 개월 전에 급격히 전환하여 인기있는 오픈 소스 인 Jenkins의 선두 제공 업체로 재 출시했습니다. 소프트웨어 개발 프로세스를 관리하기위한 소스 도구입니다.

CEO 인 Sasha Labourey에 따르면, Java PaaS 제공 업체로서 CloudBees는 "멋지게 성장"했지만 "더 큰 수표를 가진 많은 큰 기업"은 표준화가 부족한 변동성이 큰 PaaS 시장에 참여하는 것을 주저했습니다. 동시에 Jenkins는 로켓처럼 도약하고 있었고 Labourey는 특히 CloudBees가 이미 Jenkins를 서비스로 제공하고 있고 Jenkins의 제작자 인 Kohsuke Kawaguchi를 고용했기 때문에 큰 기회를 보았습니다. 젠킨스 반찬이 메인 코스가되었습니다.

젠킨스 저거너트

Jenkins의 인기 뒤에 무엇이 있습니까? 간단히 말해, Jenkins는 소스 코드 관리에서 코드 제공, 프로덕션에 이르기까지 devop의 개발 측면을 관리하기위한 오픈 소스 표준이되었습니다. Labourey에 따르면, "커뮤니티는 Jenkins를 오케스트레이션 및 자동화 엔진으로보고 있습니다. Jenkins가 사실상 엔진이 된 이유는 매우 플러그 가능하기 때문이라고 생각합니다." 1,100 개가 넘는 플러그인 에코 시스템이 등장하여 고객은 모든 종류의 기능을 추가하고 Jenkins를 Active Directory에서 GitHub, OpenShift PaaS에 이르는 모든 항목과 통합 할 수 있습니다.

Jenkins는 지속적 통합 (CI) 및 지속적 전달 (CD) 솔루션입니다. CI의 아이디어는 개별 개발자의 코드를 하루에 여러 번 프로젝트에 병합하고 다운 스트림 문제를 피하기 위해 지속적으로 테스트하는 것입니다. CD는 병합 된 모든 코드가 항상 프로덕션 준비 상태에 있도록 한 단계 더 나아갑니다. Jenkins를 사용하면 개발자가 배포 시점까지이 프로세스를 최대한 자동화 할 수 있습니다. Labourey는 예를 제공합니다.

회사에서 Chef 또는 Puppet을 사용하여 AWS에 배포한다고 가정 해보십시오. Jenkins는 그것을 대체하지 않을 것입니다. Jenkins는이를 수행하기 위해 Puppet을 호출 할 것입니다. 여기에 비트가 있습니다.이 Puppet 스크립트를 호출하여 어떻게 작동하는지 살펴 보겠습니다. 그리고 Puppet의 실행 결과는 Jenkins가 배포를 해제하고 추가 작업을 수행하기로 결정할 수 있기 때문에 중요 할 것입니다. 이를 "파이프 라인"이라고합니다. 실제로이 일련의 단계입니다. 5 단계 일 수도 있고 50 단계 일 수도 있습니다.

Jenkins는 소스에서 전달까지이 CI / CD 파이프 라인을 관리하는 워크 플로 엔진 역할을하지만 그 과정에서 다양한 기능을 수행하기 위해 다양한 도구가 호출 될 수 있다고 Labourey는 말합니다.

Docker는 이러한 도구 중 하나이며 Jenkins와 함께 Docker는 개발 팀에 큰 영향을 미치고 있습니다. Docker가 개발을 간소화하고 배포를 훨씬 더 쉽게 만든다는 것을 누구나 알고 있지만 Labourey는 개발자가 정직하게 유지하는데도 도움이된다는 사실을 알고 있습니다. 빌드가 충돌하고 번질 때 더 이상 개발 환경의 잘못된 구성을 비난 할 수 없습니다. 물리적 시스템에서는 개발 환경이 점차 손상되어 실수로 빌드가 중단됩니다. 그러나 원시 Docker 이미지 위에 코딩 할 때 빌드가 실행되지 않을 때 비난 할 자신의 결함 코드 만 있습니다.

Jenkins와 통합 에코 시스템은 함께 민첩한 개발을위한 조정 소프트웨어 인프라를 제공하고보다 광범위하게 "devops 이니셔티브의 핵심"을 형성한다고 Labourey는 말합니다.

여기에서가는 방법

이 모든 자동화 및 DevOps 효율성은 훌륭하게 들리지만, 애자일 개발에 거의 몰두하지 않은 조직은 어떻습니까? Labourey는 CI / CD 참여에 대한 조언을 제공합니다.

그렇게하는 가장 좋은 방법은 작게 시작하는 것입니다. 프로젝트를 선택하십시오. "좋아요, 이제 우리는 지속적인 배송 상점입니다. 모든 것이이 방식으로 진행됩니다."라고 말하지 마십시오. 기꺼이 다른 팀보다 더 유연하고 새로운 팀원이 될 수 있고 기존 방식에 덜 확고한 팀으로 시작하십시오. 쉬운 프로젝트를 선택하십시오. 그것이 작동한다면 모든 것이 작동 할 것이라고 말하는 방법으로 그것을 사용하려고하지 마십시오. 실패하려고하지 마십시오. 성공하려고 노력하십시오. 기꺼이 팀을 선택하고, 쉬운 프로젝트를 선택하고, 거기에 도달하십시오. 이 팀은 최고의 영업 담당자가 될 것입니다. 이제 효과가 있음을 보여줄 수 있기 때문입니다. 솔직히 옛날 방식이 지루하기 때문에 그들은 자신의 직업이 어떻게 나아 졌는지 이야기 할 수 있습니다.

Labourey는 프로세스의 일부는 "사람의 두뇌에 조용히 자리 잡고있는 지식을 추출하여 논리로 파이프 라인에 넣는 것"이라고 말합니다. 그것은 하룻밤 사이에 일어나지 않습니다. 종종 개발 조직은 CI를 망치는 것으로 시작하여 시간이 지남에 따라 CD를 향해 나아갑니다.

개발 조직은 매우 다양하고 매우 구체적인 요구 사항을 갖는 경향이 있습니다. 따라서 CloudBees는 CloudBees에서 실행하는 일반 구독 기반 SaaS 버전과 고객이 AWS 또는 Azure (또는 OpenStack에서 로컬로 배포)에 배포하고 원하는 콘텐츠에 맞게 사용자 지정할 수있는 "개인 SaaS"버전을 모두 제공합니다.

개발 프로세스의 조정, 자동화 및 간소화의 중요성을 과장하기는 어렵습니다. CI / CD는 devops의 핵심이며 성공적인 devops 구현은 IT를 넘어 비즈니스 자체로 확장되는 의미를 갖습니다. 소프트웨어를 지속적으로 개선하면 제품과 서비스가 지속적으로 개선됩니다. 예를 들어, Tesla는 자사 모델 중 하나가 불을 지르면서 심각한 좌절을 겪었고 소프트웨어 업그레이드를 출시하여 하룻밤 사이에 문제를 해결했습니다.

Labourey는 "10 % 더 높은 효율성을 얻을 수 있다면 흥미 롭습니다. IT에 1 년에 1 억 달러를 쓰면 좋습니다. 천만 달러를 다른 곳에서 사용할 수 있습니다."라고 Labourey는 말합니다. "하지만 진정한 이점은 비즈니스가 이러한 도구와 작업 방식을 활용함으로써 매출을 10 % 늘릴 수 있다는 것을 인식 할 때입니다."