Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

지속적통합

CI/CD에서 한 단계 더 나아간 '지속적 배포 자동화' 5가지 준비

많은 기업이 소프트웨어 개발 워크플로우의 효율성을 높이기 위해 지속적 통합/지속적 제공(Continuous integration/Continuous Delivery, CI/CD) 파이프라인을 앞다퉈 구축했다. 그런데 여기서 더 나아가서 CI/CD 파이프라인을 사용해서 지속적으로 프로덕션에 변경 사항을 반영하는 지속적 배포(Continuous Deployment)를 자동화한 기업은 극소수다. 여기에는 그럴 만한 이유가 있다.   사실 매일 또는 매시간 프로덕션으로 코드를 프로덕션으로 푸시한다고 생각하면 오싹한 느낌이 든다. 실제로 몇 년 전에 지속적 배포의 단점에 대한 기사를 쓴 적도 있다. “책임감 있는 데브옵스 팀이 배포 빈도를 높여야 할 때”라는 기사에서는 배포 빈도가 높을수록 좋다는 전제가 과연 옳은 전제인지를 질문했다.   그러나 지난 몇 년 사이 많은 변화가 있었고, 이제 고품질의 안정적인 배포를 자동화하기 위한 기술과 방식, 툴을 채택하는 데브옵스 팀은 점점 늘어나고 있다. 지속적 제공과 지속적 배포 간의 차이점을 설명하고, 데브옵스 팀이 CI/CD 파이프라인의 지속적 배포를 자동화하기 전에 해야 할 5가지를 살펴본다.   지속적 제공 vs. 지속적 배포 캡제미니(Capgemini)의 애자일 및 데브옵스 리더인 쿨버 라이나는 지속적 제공과 지속적 배포의 차이점에 대해 “지속적 제공은 프로덕션에 이르기까지 소프트웨어 릴리즈의 종단 간 자동화 흐름이고, 지속적 배포는 지속적 통합 이후 이 흐름에서 사전에 테스트된 프로세스를 통해 프로덕션으로 소프트웨어 패키지를 푸시하는 자동화된 프로세스”라고 설명했다.   프로덕션 배포 자동화는 그 결과가 비즈니스, 고객, 최종 사용자에게 영향을 미치는 만큼 위험도 크다. 그래서 데브옵스 팀이 배포를 자동화하기로 결정하는 경우 배포 프로세스에는 지속적 테스트와 철저한 오류 처리가 포함되어야 한다. 그렇지 않으면 배포로 인해 프로덕션에서 성능 문제, 불안정한 시스템, 보안 틈새 및 ...

CI/CD 지속적배포 지속적제공 2022.06.23

“CI/CD란?” 알기 쉽게 설명한 지속적 통합과 지속적 제공

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

CI/CD 지속적통합 지속적제공 2022.04.20

도커와 젠킨스로 시작하는 실전 CI/CD 구현 가이드 - IDG DeepDive

젠킨스(Jenkins)는 다른 일상적인 개발 작업을 자동화할 뿐 아니라 파이프라인에 걸쳐 거의 모든 언어의 조합과 소스코드 리포지토리에 대한 지속적 통합/지속적 배포(CI/CD) 환경을 구축하는 직관적인 방법을 제공한다. 단계별 스크립트는 여전히 작성해야 하지만, 사용자가 더 빠르고 강력하게 빌드, 테스트, 그리고 배포 등 체인 전체를 통합할 수 있다. 도커와 젠킨스, CI/CD의 개념을 알아보고, 이를 이용해 직접 CI/CD를 구현하는 과정을 차근차근 설명한다. 주요 내용 - “빌드·테스트·배포의 통합” 젠킨스와 CI 서버의 이해 - 젠킨스를 이용한 '지속적 통합' 구축 실전 - 도커와 젠킨스로 CI를 구현하는 방법

도커 젠킨스 CI 2022.01.12

도커와 젠킨스를 이용해 지속적 통합을 구현하는 방법

지속적 통합과 지속적 제공(CI/CD)을 구현하는 방법은 다양하지만, 여러 이유로 보통은 도커(Docker)와 같은 컨테이너 앱을 사용한다. 컨테이너화가 이뤄진 후에 CI 파이프라인에 중요한 요소는 체크인 시 이미지를 빌드하고 테스트를 실행한 다음 후속 단계에서 사용하기 위해 도커 허브(Docker Hub) 또는 다른 레지스트리에 이 이미지를 게시하는 것이다.    젠킨스(Jenkins)를 설정해 깃허브에서 업데이트된 애플리케이션 코드를 가져와 도커 이미지를 빌드하고 테스트를 실행하고 레지스트리에 게시하는 방법을 살펴보자. 여기서는 간단한 자바 앱을 사용하지만 다른 스택에서도 과정은 대체로 비슷하다.    도커 허브에 게시하기 자바, 젠킨스, 도커의 기본적인 사항은 이 기사를 참고하고, 여기서는 한 걸음 더 나아가 최신 깃허브 체크인을 가져오고 앱의 도커 이미지를 빌드하고 이를 도커 허브에 게시하는 방법을 알아보자. 무료인 도커 허브 계정이 필요하다.  중앙 컨테이너 이미지 리포지토리(이 경우 도커 허브)에 게시하는 것은 기업 CI/CD의 핵심 요소다. QA에서 테스트, 프로덕션에 이르는 다양한 단계에서 아티팩트를 재사용하기 위한 공통된 장소가 바로 이미지 리포지토리이기 때문이다.   젠킨스와 도커-인-도커 실행하기 도커를 실행하도록 젠킨스를 설정하기 위해 VM에서 도커 이미지 2개를 실행한다. 한 컨테이너는 도커 자체에서 액세스하기 위한 '도커-인-도커'(docker:dind 이미지)를 호스팅하고, 다른 하나는 젠킨스를 호스팅한다. 두 컨테이너는 네트워크와 볼륨을 통해 상호작용한다. 이런 방식은 젠킨스 안내서에서 권장하는 방법이기도 하다. 먼저 원하는 클라우드 서비스에서 새 VM을 만든다. 여기서는 구글 클라우드 플랫폼(GCP)을 사용한다. 이 아키텍처를 빠르게 시작하는 방법은 도커와 도커-인-도커 이미지를 이미 설치된 VM으로 시작하는 것이다. GCP 콘솔에서 컴퓨트 엔진(Compute Engin...

도커 젠킨스 지속적통합 2021.10.27

서비스로서의 CI/CD : 클라우드의 지속적 통합과 제공을 위한 10가지 툴

클라우드와 지속적 통합(Continuous Integration, CI)은 잘 맞는 한 쌍이다. 클라우드는 물리 서버를 설치하고 유지보수하는 고통을 없애고, CI는 코드를 빌드, 테스트, 배포하는 데 따르는 힘든 작업의 대부분을 자동화한다. 두 가지 기술 모두 개발 팀이 짊어지는 부담을 덜어주는 데 목표를 두니, 둘을 결합해서 더 많은 단순 작업을 없앨 수 있다면 금상첨화일 것이다. CI 서비스는 숫자도 많고 적어도 추상적 관점에서는 기능도 대부분 동일하다. CI 서비스에서 가장 먼저 하는 일은 사용자가 개발한 새로운 소프트웨어의 뛰어남을 온 세상에 알리기 전에 해야 할 일, 즉 컴파일, 테스트와 같은 작업을 목록화하는 것이다. 코드를 작성해서 커밋하면 툴이 체크리스트에 따라 장애물이 있는지 여부를 살핀다. 장애물이 없다면 최상이다.   누구나 소프트웨어 개발 프로젝트에서 CI를 사용할 수 있지만, 가장 큰 이득을 얻는 쪽은 팀, 주로 상호 연계되는 코드 블록으로 작업하는 대규모 팀이다. 철저한 CI 구현은 빌드와 테스트를 계속 반복하면서 여러 팀원이 각자의 코드를 체크인하는 과정에서 발생했을지도 모를 새로운 오류와 비호환성을 찾는다. 지속적 통합 서버는 모든 프로그래머의 작업을 동기화하고 문제를 발견하도록 돕는다. 테스트를 CI 서버 작업 목록의 마지막 요소로 보는 시각도 있지만, 최근에는 신규 코드 배포, 즉 “지속적 배포(Continuous Deployment)” 프로세스를 포함하도록 작업 목록을 확장하는 팀이 늘고 있다. 완전히 자동화된 배포에 안심하지 못하는 사람들은 프로세스에 몇 가지 수작업을 추가하는 경우가 많다. 책임 소재와 사람의 확인이 있어야만 안심이 되기 때문이다. 이러한 혼합적 접근 방식을 “지속적 제공(Continuous Delivery, CD)”이라고 지칭한다. 코드는 스테이징 또는 테스팅 클러스터로 전달된 후 거기서 사람이 프로덕션으로 푸시하는 최종 단계를 기다리게 된다...

파이프라인 CI/CD 지속적통합 2019.03.21

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.