목차
Jenkins
Jenkins란 오픈소스 CI/CD 도구 입니다.
Jenkins는 빌드, 테스트, 배포 등의 프로세스를 자동화하고 스케줄링하여 소프트웨어 품질과 개발 생산성을 향상시킵니다. 또한, Jenkins는 다양한 플러그인을 통해 기능을 확장하므로 다양한 도구와 통합할 수 있습니다.
Jenkins를 사용하면 개발자들은 크게 두 가지 이점을 얻을 수 있습니다.
첫째, Jenkins를 사용하면 개발자들은 반복적인 업무를 자동화하여 버그를 빠르게 찾아내거나 변경사항을 빠르게 적용할 수 있어 고객에게 빠르게 서비스를 제공(배포) 할 수 있습니다. 즉, 고객의 요구사항에 빠르게 대응할 수 있개 해줍니다.
둘째, 고객에게 서비스를 제공하기 위한 빌드, 테스트, 배포 과정이 자동화됨으로 개발자가 수동으로 해야할 작업들이 줄어들어 시간을 절약할 수 있게 해줍니다.
CI / CD
Jenkins는 CI/CD 도구라고 말했습니다.
Ci란 Continuous Integration의 약자로 지속적 통합을 뜻 합니다. 코드를 지속적으로 합하는 것을 CI라고 합니다.
CD는 Continuous Deployment의 약자로 지속적 배포를 뜻 합니다. 통합된 코드를 고객에게 배포하는 것을 CD라 합니다.
위의 과정은 Docker를 이용한 CI/CD를 구현한 한 예 입니다.
그렇다면 CI/CD에 대해 자세히 알아보도록 하겠습니다.
CI
CI는 Continuous Integration의 약자로 지속적 통합을 의미합니다.
CI란 개발자가 코드의 변경 사항을 공유 저장소에 빈번하게 통합하고 이를 자동화된 빌드와 테스트를 통해 검증하는 개발 방법론 입니다.
CI를 도입하는 주된 목적은 코드의 품질을 향상시키고, 버그를 빠르게 찾아 해결하며, 개발 및 배포 프로세스의 효율성을 높이는 것 입니다. 이를 통해 고객의 요구사항을 빠르게 반영하여 비즈니스 가치를 극대화 합니다.
그렇다면 CI는 어떻게 위와 같은 이점을 제공하는 것일까요?
그 핵심은 빈번한 통합과 Build와 Test의 자동화 입니다.
1. 빈번한 통합
개발자들이 하나의 애플리케이션을 개발하고 있으며 버전 관리 시스템(git, svn 등..)을 사용하고 있다고 가정해 봅시다.
개발자들이 빈번하게 merge를 하지 않고 오랜 시간 개발한 코드를 한 번에 merge를 하면 어떻게 될까요?
분명 충돌되는 코드들이 많이 생겨날 것 입니다. 이렇게 된다면 새로운 기능의 코드를 작성하는 시간보다 충돌된 많은 코드들을 수정하는데 시간이 더 오래 걸릴 수 있습니다. 이는 매우 비효율적이며 그렇기에 가능한 작은 단위로 나누어 주기적으로 개발한 코드를 빈번하게 통합하는 것이 중요합니다.
빈번의 통합의 장점을 정리하면 다음과 같습니다.
첫 번째는 코드 충돌 방지로 인한 더 나은 협업 입니다. CI를 도입하면 모든 개발자가 같은 버전의 최신 코드로 작업을 진행하므로, 코드 충돌을 최소화하고 일관성을 유지하는데 도움이 됩니다.
두 번째는 버그를 빠르게 찾아 해결할 수 있다는 것 입니다. 빈번한 통합을 통해 새로운 코드 변경 사항이 기존의 코드와 잘 작동하는지 확인할 수 있습니다. 이는 Build와 Test를 통해 이루어지면 이를 통해 버그를 빠르게 찾아 해결할 수 있습니다.
세 번째는 지속적인 피드백을 제공한다는 것 입니다. 빈번한 통합은 개발자가 개발한 작업이 프로젝트 전체와 어떻게 상호작용 하는지 지속적인 피드백을 받을 수 있습니다.
네 번째는 소프트웨어 배포 준비 입니다. 빈번한 통합을 통해 코드는 언제든 배포 가능한 상태를 유지할 수 있습니다.
즉, 빈번한 통합은 코드 통합 주기를 짧게 유지해 통합의 복잡성을 감소시키고 버그를 빠르게 찾아내어 문제를 해결하여 프로젝트의 전반적인 생산성과 효율성을 향상시키고 완성 시간 단축이 기여합니다.
그렇다면 빈번한 통합의 문제점은 무엇일까요? 바로 단순 작업이 반복되는 것 입니다.
이를 해결하기 위해 나온 것이 단순 작업의 자동화 입니다.
2. Build와 Test의 자동화
소프트웨어 개발의 복잡성과 규모가 증가함에 따라, 수작업으로 Build와 Test를 진행하는 것은 점점 더 비효율적인 일이 되었습니다.
이를 해결하기 위해 CI 툴은 버전 관리 시스템에서 코드 변경 사항을 주기적으로 감지하고, 이를 자동으로 Build 및 Test 하는 기능을 제공합니다. 이는 개발자가 새로운 코드를 저장소에 Push 하자마자 자동적으로 통합과정을 시작합니다.
자동화를 도입하면서 얻는 이점들은 다음과 같습니다.
첫 번째는 시간 절약 입니다. Build와 Test 과정이 자동화되면 개발자들은 수동으로 진행하는데 소요되는 시간을 다른 중요한 작업에 활용할 수 있어 생산성이 증가하게 됩니다.
두 번째는 오류의 감소 입니다. 수작업에서는 실수로 인한 오류가 발생할 수 있지만, 자동화된 과정에서는 이러한 실수를 피할 수 있습니다.
세 번째는 프로젝트의 일관성이 보장 됩니다. 동일한 Build와 Test 과정이 반복되므로 소프트웨어 배포를 위한 환경 및 절차의 일관성이 보장됩니다. 이는 배포 과정에서 예상치 못한 문제 발생을 방지하며, 소프트웨어 품질을 일관되게 유지하는데 도움이 됩니다.
CD
CD는 Continuous Delivery 지속적인 제공이라는 의미와 Continuous Deployment 지속적인 배포를 의미가 있습니다.
CD는 소프트웨어를 신속하고 지속적으로 고객에게 제공하는 개발 방식이란 뜻 입니다.
CD의 핵심은 소프트웨어가 항상 배포 가능한 상태를 유지하는 것 입니다.
즉 CI를 통해 변경된 코드를 통합했다면 CD를 통해 통합된 코드를 배포하는 것 입니다.
CI와 마찬가지로 CD도 배포하는 과정을 자동화함으로써 변경 사항을 빠르게 반영해 배포하게 해줍니다.
CD를 도입하면 두 가지 효과를 얻을 수 있습니다.
첫 번째, 개발자가 소프트웨어를 빠르게 출시할 수 있게 해줍니다.
고객의 피드백을 더 빨리 받아들이고, 그에 따라 제품을 개선하는데 있어 중요한 역할을 합니다.
두 번째, 자동화된 배포 과정은 개발자가 수동으로 수행해야 할 작업을 줄여줍니다.
이는 시간을 절약하고 오류 발생 가능성을 줄여줍니다.
CD는 오늘날 빠르게 변화하는 시장 환경에서 소프트웨어 개발팀이 더 효율적으로 작동하고, 고객의 요구사항을 더 빨리 대응할 수 있도록 돕는 핵심 개발 전략 입니다.
Pipeline
CI/CD 를 이루기 위해서 자동화는 필수라는 것을 알았습니다. 그렇다면 자동화는 어떤 식으로 구현이 될까요?
CI/CD 일련의 과정을 Pipeline 구축을 통해 자동화를 구현하게 됩니다.
Pipeline 이란 데이터나 명령어가 처리되는 일련의 단계를 의미하며, 특히 소프트웨어 개발에서는 개발, 테스트, 배포 등의 단계를 자동화하고 일련의 흐름으로 연결하는 프로세스를 가리킵니다.
위의 이미지와 같이 변경된 코드가 반영된 소프트웨어를 배포하기 위해서는 일련의 과정을 거쳐야 합니다.
대체적으로 Commit, Build, Test, Stage, Deploy 과정을 거칩니다.
Commit : 개발자들이 작성한 코드를 형상 관리 도구(Git..)에 저장합니다. Jenkins는 이 변화를 감지하고 작업을 시작합니다.
Build : 소스코드가 실행 가능한 소프트웨어로 변환되는 단계입니다. 이 과정에서 컴파일, 유닛 테스트 실행, 아티팩트 생성이 실행됩니다.
Test : Build 단계에서 생성된 아티팩트는 다양한 테스트를 거칩니다. 이를 통해 품질을 보증하고 이후 단계에서 발견될 문제를 미치 찾아내는데 도움이 됩니다.
Staging : 테스트를 통과하면, 소프트웨어는 스테이징 환경으로 이동합니다. 이는 프로덕션 환경을 모사한 환경으로, 실제 배포 전에 추가적인 테스트를 수행합니다.
Deploy : 스테이팅 단계를 통과하면 소프트웨어는 프로덕션 환경에 배포됩니다.
Jenkins는 위의 과정을 자동화하고 관리합니다. 또한 사용자가 원하는대 맞춤화된 워크플로우를 만들 수 있게 해줍니다.
프로젝트의 요구사항에 맞게 파이프라인의 단계를 다르게 설정하거나, 필요한 도구를 통합하거나, 특정한 작업을 자동화 할 수 있습니다.
Jenkinsfile
Jenkins 파이프라인은 jenkinsfile 이라는 텍스트 파일에 작성됩니다. 이 파일은 소스 코드와 함께 버전 관리 시스템에 저장될 수 있습니다. 이를 통해 파이프라인의 변경 사항을 추적하고, 이전 버전으로 롤백도 가능합니다.
Jenkinsfile은 Declarative Pipeline 혹은 Scripted Pipeline 형식으로 작성이 됩니다.
Declarative Pipeline
이 형식은 더 간결하고 이해하기 쉬운 구문을 제공합니다.
Jenkinsfile은 pipeline {} 블록 내부에 정의되며 stage {} 블록 내부에 개별 단계들이 정의됩니다.
이 형식은 파이프라인의 구조와 실행을 명확하게 정의하므로 복잡한 로직을 필요로 하지 않을 때 사용합니다.
대부분의 경우 Declarative Pipeline 을 사용합니다.
Scripted Pipeline
이 형식은 유연한 구성을 제공하지만 Groovy 스크립팅 언어에 대한 이해가 필요합니다.
복잡한 로직을 필요로 할 때 사용되면 Declarative Pipeline 구조에 맞지 않은 파이프라인을 구성할 때 사용합니다.
Jenkins Pipeline 은 사용자가 요구 사항에 맞는 워크플로우(파이프라인)를 구성할 수 있게 합니다. 이러한 유연성이 Jenkins를 인기 있는 CI/CD 도구로 만들었습니다.
Plugin
Plugin은 기존 소프트웨어의 기능을 확장하거나 새로운 기능을 추가하는 소프트웨어 컴포넌트를 의미합니다.
Jenkins 와 같은 CI/CD 도구에서도 플러그인은 중요한 역할을 합니다.
플러그인을 사용하면 Jenkins의 기본 기능을 확장하거나, 다른 개발 도구와 통합하거나, 특정 작업을 자동화하는데 필요한 새로운 기능을 추가할 수 있습니다. 즉, 사용자가 원하는 파이프라인을 만드는데 필요한 기능이 Jenkins 기본 제공 기능에 없는 경우 플러그인을 사용하여 기능을 추가할 수 있습니다.
Jenkins는 이러한 이유로 매우 큰 플러그인 생태계를 가지고 있으며, 필요한 플러그인을 찾아 설치하고 사용해 사용자들이 원하는 파이프라인을 구축하는데 큰 도움을 줍니다.
플러그인이 제공하는 기능을 사용하면 복잡한 작업을 단순화하고, 파이프라인을 더 명확하고 이해하기 쉽게 만들 수 있습니다.
