바라보기, 찾기, CI / CD, continuous integration / continuous delivery, deployment, 지속적 통합, 지속적 배포

바라보기, 찾기, CI / CD, continuous integration / continuous delivery, deployment, 지속적 통합, 지속적 배포

 

소프트웨어 공학에서 CI/CD는 지속적 통합(영어: continuous integration)과 지속적 배포(영어: continuous delivery, CD)가 결합한 사례를 의미한다. CI/CD는 소프트웨어의 개발, 테스트와 배포를 모두 통합함으로써 소프트웨어 버그를 쉽게 찾아낼 수 있으며, 더 빠른 배포 주기를 가질 수 있게 만들어 준다. -위키백과

 

---

소프트웨어 공학에서 지속적 통합(continuous integration, CI)은 지속적으로 품질 관리(Quality Control)를 적용하는 프로세스를 실행하는 것이다. - 작은 단위의 작업, 빈번한 적용. 지속적인 통합은 모든 개발을 완료한 뒤에 품질 관리를 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점이 맞추어져 있다. 대표적인 CI 툴에는 젠킨스(Jenkins)가 있다.

개발자가 기존 코드의 수정 작업을 시작할 때, 일반적으로 현재의 코드 베이스의 복사본을 받아서 거기로부터 작업을 시작한다. 한편, 다른 개발자들이 자신들이 변경한 코드를 소스 코드 저장소에 제출하면, 코드 베이스로부터 받아온 복사본은 저장소 코드와 점차 달라진다. 코드 베이스만 변하는 것이 아니라, 새 라이브러리가 추가되거나 그 밖에 의존성 문제가 생길 수 있는 다양한 변화들이 생길 수 있다.

개발자들이 저장소에 코드를 제출하려면, 먼저 자신이 코드를 받았던 때부터 현재까지 저장소 코드의 변경 내용을 자신의 코드에 반영되도록 자신의 코드를 업데이트한 후 자신의 코드를 제출해야 한다. 저장소에 변경된 내용이 많을수록, 개발자들이 자신의 작업 내용을 제출하기 전에 해야 할 일이 많아진다.

언젠가는 저장소가 개발자들의 베이스라인과는 너무 많이 달라지게 되는 "통합의 지옥"[1] 이라 불리는 상황에 빠지게 된다. 이 경우, 작업하는 시간보다 작업 내용을 통합하는데 걸리는 시간이 더 걸리게 되어, 최악의 경우 개발자들이 자신들의 변경 내용들을 취소하고 작업들을 완전히 처음부터 다시하는 것이 나을 수도 있다.

지속적인 통합은 초기에 그리고 자주 통합해서 "통합의 지옥"의 함정을 피하는 것을 내포하고 있다. 지속적인 통합은 재작업을 줄여서 비용과 시간을 줄이는데 초점이 맞추어져 있다.

지속적인 통합을 적용하지 않으면, 각각의 프로그래머가 자신이 작업한 것을 제출하기 전에 반드시 완벽한 빌드와 테스트를 해야 한다. 모든 프로그래머들은 저장소로부터 프로젝트를 업데이트하는 것으로 하루를 시작해야 한다. 그러면, 그들은 모든 것들을 최신의 상태로 유지할 수 있을 것이다.-위키백과

---

지속적 배포(Continuous delivery, CD)는 팀이 짧은 주기로 소프트웨어를 개발하는 소프트웨어 공학적 접근의 하나로, 소프트웨어가 언제든지 신뢰 가능한 수준으로 출시될 수 있도록 보증하기 위한 것이다.[1] 소프트웨어를 더 빠르게, 더 주기적으로 빌드하고 테스트하고 출시하는 것을 목표로 한다. 이러한 접근은 더 많은 증분 업데이트를 업무 애플리케이션에 적용할 수 있게 함으로써 변경사항의 배포에 대한 비용, 시간, 위험을 줄일 수 있게 한다.

---

데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

 

데브옵스의 목적은 전반적인 배포 파이프라인에 걸쳐있다. 여기에는 개선된 배치(deployment) 주기를 포함하며 다음으로 이어질 수 있다:

• 제품 출시까지 걸리는 기간(time to market) 단축
• 새로운 판의 더 낮은 실패율
• 픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)
• 복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)

단순한 프로세스들은 데브옵스 접근을 사용하여 더 프로그래밍 가능하게 되고 유동적으로 되고 있다.[1] 데브옵스는 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적이다. 더 가끔씩 자동화가 이러한 목표를 지원한다.

 

1. 계획 - 목적을 수행하기 앞서 방법이나 절차 등을 미리 생각하여 계획.
2. 코드 - 코드 개발 및 검토, 버전 관리 도구, 코드 병합
3. 빌드 - 지속적 통합(CI) 도구, 빌드 상태
4. 테스트 - 테스트 및 결과가 성능을 결정
5. 패키지 - 애플리케이션 디플로이 이전 단계
6. 릴리스 - 변경사항 관리, 릴리스 승인, 릴리스 자동화
7. 구성 - 인프라스트럭처 구성 및 관리, IaC(Infrastructure as Code) 도구
8. 모니터링 - 애플리케이션 성능 모니터링, 최종 사용자 경험.

---

지속적 통합이란?

CI/CD에서 "CI"는 언제나 지속적 통합을 의미하며, 지속적 통합은 코드 변경 사항을 다시 공유 분기 또는 "트렁크"로 더 빈번하게 병합하는 것을 용이하게 하는 개발자용 자동화 프로세스입니다. 이러한 업데이트가 이루어지면 병합된 코드 변경 사항의 신뢰성을 보장하기 위해 자동화된 테스트 단계가 트리거됩니다. 

현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 합니다. 그러나 조직에서 특정한 날("병합의 날(merge day)")을 정해 모든 분기 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간을 소모하게 됩니다. 

이는 고립된 상태에서 작업하는 개발자가 애플리케이션을 변경하는 경우 다른 개발자들이 동시에 적용하는 여러 변경 사항들과 충돌할 가능성이 있기 때문입니다. 팀이 하나의 클라우드 기반 통합 개발 환경(Integrated Development Environment, IDE)에 동의하지 않고 각 개발자가 각자의 로컬 IDE를 커스터마이징하는 경우 문제는 더 심화될 수 있습니다.

동시에 개발 중인 애플리케이션의 분기가 너무 많아 상호 충돌할 가능성이 있는 문제에 대한 해결책으로 CI를 고려할 수 있습니다.

성공적인 CI란 개발자가 애플리케이션에 적용한 변경 사항들이 병합된 후 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 빌드하고 다양한 수준의 자동화된 테스트(일반적으로 단위 테스트와 통합 테스트)를 실행하여 해당 변경 사을 검증하는 것입니다. 즉, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 다양한 모듈에 이르기까지 모든 것을 테스트합니다. 자동화된 테스트를 통해 새 코드와 기존 코드 간 충돌이 발견되는 경우 CI를 적용하면 해당 버그를 빠르게, 자주 수정하기가 더 용이해집니다.

 

지속적 제공이란?

 지속적 제공은 CI에서 빌드와 단위 및 통합 테스트를 자동화한 다음 검증된 코드를 리포지토리로 릴리스하는 것을 자동화합니다. 따라서 효과적인 지속적 제공 프로세스를 마련하려면 CI가 개발 파이프라인에 이미 구축되어 있어야 합니다.

지속적 제공의 경우, 코드 변경 사항의 병합부터 프로덕션 레디 빌드의 제공에 이르기까지 모든 단계에 테스트 자동화와 코드 릴리스 자동화가 수반됩니다. 이 프로세스가 종료되면 운영 팀은 애플리케이션을 프로덕션으로 신속하게 배포할 수 있습니다.

일반적으로 지속적 제공이란 개발자의 애플리케이션 변경 사항이 자동으로 버그 테스트를 거치고 리포지토리(예: GitHub, 컨테이너 레지스트리)로 업로드된다는 것을 의미합니다. 이후 리포지토리에서 운영 팀이 변경 사항을 라이브 프로덕션 환경으로 배포할 수 있습니다. 그 결과 개발 팀과 비즈니스 팀 간 가시성 및 의사 소통 부족 문제가 해결될 수 있습니다. 이를 위한 지속적 제공의 목표는 언제나 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 갖추고 새로운 코드를 배포하는 데 필요한 노력을 최소화하는 것입니다.

 

 

https://www.redhat.com/ko/topics/devops/what-is-ci-cd.

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이

---

• Introduction
• Chapter 1: What Is DevOps?
• Chapter 2: Where Did DevOps Come From?
• Chapter 3: What Problems Led to the Creation of DevOps?
• Chapter 4: DevOps, Agile, and SRE Explained
• Chapter 5: How Does DevOps “Work”?
• Chapter 6: Who’s Adopting DevOps?
• Chapter 7: Why Are Your Peers Embracing DevOps?
• Chapter 8: How Will I Benefit From DevOps?
• Conclusion

 

Chapter 1: What Is DevOps?

The word “DevOps” was coined in 2009 by Patrick Debois, who became one of its gurus. The term was formed by combining “development” and “operations,” which provides a starting point for understanding exactly what people typically mean when they say “DevOps.” Notably, DevOps isn’t a process or a technology or a standard. Many devotees refer to DevOps as a “culture”—a viewpoint that New Relic favors. We also use the term “DevOps movement” when talking about topics such as adoption rates and trends for the future, and “DevOps environment” to refer to an IT organization that has adopted a DevOps culture.

This primer will have a great deal more to say about DevOps, but to get started, we need a serviceable definition. We like this one from Gartner:

“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology— especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

Importantly, the meaning of DevOps has broadened to be an umbrella term for the processes, culture, and mindset used to shorten the software development life cycle, using fast feedback loops to deliver features, fixes, and updates more frequently.

https://newrelic.com/devops/what-is-devops