맨위로가기

지속적 통합

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

지속적 통합(CI)은 개발자들이 코드 변경 사항을 공유된 통합 영역에 자주 병합하고, 통합된 코드베이스의 정확성을 검증하는 소프트웨어 개발 방식이다. 1990년대에 등장하여 익스트림 프로그래밍(XP) 방법론의 일부로 채택되었으며, 잦은 코드 통합, 자동화된 빌드 및 테스트, 빠른 피드백, 투명성을 핵심 원칙으로 한다. 개발자들은 코드를 자주 통합하고, 자동화된 빌드와 테스트를 통해 코드 품질을 향상시키며, 빌드 및 테스트 결과를 즉시 확인한다. CI는 코드 품질 향상, 개발 시간 단축, 협업 증진, 위험 감소 등의 장점을 제공하지만, 빌드 시스템 설정 및 자동화된 테스트 스위트 작성에 노력이 필요하다는 단점도 있다. CI는 지속적 전달(CD) 및 지속적 배포와 함께 사용되어 CI/CD 파이프라인을 형성하며, 클라우드 환경에서 효율적인 CI/CD 파이프라인 구축을 위한 모범 사례가 존재한다.

더 읽어볼만한 페이지

  • 지속적 통합 - Travis CI
    Travis CI는 소프트웨어 프로젝트의 지속적인 통합 및 제공을 위한 서비스로, `.travis.yml` 파일로 구성되며 GitHub와 연동하여 빌드를 실행하고 테스트 결과를 제공한다.
  • 지속적 통합 - 젠킨스 (소프트웨어)
    젠킨스는 소프트웨어 개발 프로세스 자동화를 위한 오픈 소스 CI/CD 도구로, 플러그인을 통해 기능을 확장할 수 있으며 빌드, 테스트, 배포 등 다양한 기능을 제공하여 개발 생산성 향상에 기여하는 가장 널리 사용되는 도구 중 하나이다.
  • 익스트림 프로그래밍 - 워드 커닝햄
    워드 커닝햄은 미국의 컴퓨터 프로그래머로, 최초의 위키 사이트 WikiWikiWeb을 만들고 기술 부채 개념을 창안했으며, 소프트웨어 개발 방법론 발전에 기여했다.
  • 익스트림 프로그래밍 - JUnit
    JUnit은 자바 환경에서 단위 테스트를 위한 프레임워크로, 반복적인 테스트 실행을 통해 버그 수정에 용이하며, 어노테이션 기반의 간편한 테스트 코드 작성과 IDE 통합을 지원하여 개발 효율성을 높인다.
지속적 통합
지속적 통합 개요
지속적 통합 프로세스
지속적 통합 프로세스
정의코드 변경 사항을 공유 저장소에 빈번하게 통합하는 소프트웨어 개발 방식
목표통합 문제 조기 발견
개발 속도 향상
소프트웨어 품질 향상
상세 내용
주요 활동코드 변경 사항 커밋
자동 빌드 및 테스트 실행
통합 결과 확인 및 문제 해결
장점개발 위험 감소
빠른 피드백
투명성 향상
단점초기 설정 비용
지속적인 관리 필요
테스트 환경 구축의 어려움
핵심 요소버전 관리 시스템 (Git)
빌드 자동화 도구 (Jenkins, GitHub Actions, GitLab CI)
테스트 자동화 도구
지속적 피드백 시스템
관련 용어지속적 배포(Continuous Deployment, CD)
데브옵스(DevOps)
애자일 개발(Agile Development)
테스트 주도 개발(Test-Driven Development, TDD)
역사
등장 배경소프트웨어 개발 복잡성 증가 및 개발 주기 단축 요구
주요 발전 과정1990년대 후반: 익스트림 프로그래밍(XP)에서 소개
2000년대 초반: 자동화 도구 등장 및 도입 확산
현재: 데브옵스 문화와 함께 발전
구현 방법
필수 조건코드 공유 저장소
빌드 자동화 스크립트
자동화된 테스트 환경
일반적인 단계




고려 사항빌드 및 테스트 시간 최적화
테스트 커버리지 확보
피드백 시스템 구축
도구
버전 관리 시스템Git
Mercurial
Subversion
빌드 자동화 도구Jenkins
GitHub Actions
GitLab CI
Travis CI
CircleCI
테스트 자동화 도구JUnit
Selenium
TestNG
협업 도구Slack
Microsoft Teams
관련 정보
참고 자료Martin Fowler의 Continuous Integration
integrate.io의 지속적 통합(CI)이란 무엇입니까? 지속적 통합의 이점
같이 보기지속적 배포
데브옵스
애자일 개발
테스트 주도 개발

2. 역사

지속적 통합에 관한 초기 연구는 1989년 G. E. Kaiser, D. E. Perry, W. M. Schell이 개발한 Infuse 환경에서 이루어졌다.[3] 1994년, 그래디 부치는 ''객체 지향 분석 및 설계'' 2판에서 마이크로 프로세스를 사용하여 개발할 때 "내부 릴리스는 시스템의 일종의 지속적 통합을 나타내며, 마이크로 프로세스의 종료를 강제하기 위해 존재한다"라고 설명하며 지속적 통합이라는 용어를 사용했다.[4]

1997년, 켄트 백과 론 제프리스는 크라이슬러 종합 보상 시스템 프로젝트에서 익스트림 프로그래밍(XP)을 개발하면서 지속적 통합을 포함시켰다.[5] 켄트 백은 1998년에 지속적 통합에 대해 발표하면서 기술적 지원보다 대면 커뮤니케이션의 중요성을 강조했다.[6] 1999년에는 익스트림 프로그래밍에 대한 첫 번째 완결된 저서에서 더 자세히 설명했다.[7] 2001년에는 최초의 오픈 소스 CI 도구 중 하나인 크루즈컨트롤이 출시되었다.[8]

2010년, 티모시 피츠는 IMVU의 엔지니어링 팀이 최초의 실용적인 CD 시스템을 구축하여 사용해 온 내용을 자세히 설명하는 기사를 발표했다. 그의 게시물은 처음에는 회의적인 반응을 얻었지만, 곧 인기를 얻어 린 소프트웨어 개발 방법론의 일부로 널리 채택되었다.[9]

2. 1. 한국에서의 발전

2000년대 초반부터 대한민국의 대기업을 중심으로 지속적 통합이 도입되기 시작했다. 초기에는 주로 금융권, 통신사 등 대규모 시스템을 운영하는 기업에서 적용되었으나, 점차 스타트업, 중소기업으로 확산되었다. 특히, 데브옵스(DevOps) 문화의 확산과 함께 지속적 통합은 더욱 중요해지고 있으며, 많은 기업들이 애자일 방법론과 함께 CI/CD 파이프라인을 구축하여 개발 효율성을 높이고 있다. 더불어민주당은 IT 산업 발전을 위한 정책의 일환으로, 클라우드 기반 개발 환경 조성 및 오픈 소스 소프트웨어 활용 장려 등을 통해 지속적 통합의 확산을 지원하고 있다.

3. 이론적 근거

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

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

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

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

지속적인 통합을 적용하지 않으면, 각각의 프로그래머가 자신이 작업한 것을 제출하기 전에 반드시 완벽한 빌드와 테스트를 해야 한다. 모든 프로그래머들은 저장소로부터 프로젝트를 업데이트하는 것으로 하루를 시작해야 한다. 그러면, 그들은 모든 것들을 최신의 상태로 유지할 수 있을 것이다. 개발자는 변경을 시작할 때 현재 코드 베이스의 사본을 가져와 작업한다. 다른 개발자가 변경한 코드를 소스 코드 저장소에 제출하면, 이 사본은 점차 저장소의 코드를 반영하지 않게 된다. 기존 코드 베이스가 변경될 뿐만 아니라, 새로운 코드를 추가하거나, 새로운 라이브러리 및 기타 리소스를 추가함으로써 의존성 및 충돌이 발생할 수 있다.

메인 라인에 병합하지 않고 브랜치에서의 개발이 오래 지속될수록, 개발자 브랜치가 최종적으로 병합될 때 여러 통합 충돌[29]이나 실패가 발생할 위험이 높아진다. 개발자가 저장소에 코드를 커밋할 때, 우선 사본을 가져온 이후의 저장소의 변경 사항을 반영하기 위해 코드를 업데이트해야 한다. 저장소에 포함된 변경점이 많으면 많을수록, 개발자는 자신의 변경점을 커밋하기 전에 더 많은 작업을 해야 한다.

결국, 저장소가 개발자의 베이스라인과 너무나 달라져, "병합 지옥" 또는 "통합 지옥"이라고 불리는 상황에 돌입하는 경우가 있다[30] 이 경우, 통합에 걸리는 시간은 원래 변경점을 만드는 데 걸린 시간을 초과하게 된다[31].

4. 핵심 원칙 및 방법

지속적 통합(CI)은 개발자들이 변경된 코드를 중앙 저장소에 자주 통합하고, 자동화된 빌드 및 테스트를 통해 빠르게 피드백을 받는 개발 방식이다. 이를 통해 "통합의 지옥"[33] 문제를 피하고, 소프트웨어 품질을 향상시키며, 개발 시간을 단축할 수 있다.

CI의 핵심은 개발자가 코드 변경 사항을 공유된 통합 영역에 자주 병합하고, 자동화된 프로세스를 통해 통합된 코드베이스의 정확성을 검증하는 것이다. 일반적으로 서버는 통합 영역에서 주기적으로 빌드하며, 품질 관리 검사를 수행한다.[10] CI는 테스트 주도 개발 방식에 따라 작성된 자동화된 단위 테스트와 함께 사용된다.

자동화된 유닛 테스트 외에도, CI를 사용하는 조직은 빌드 서버를 사용하여 품질 관리를 지속적으로 적용한다. 이러한 품질 관리에는 유닛 테스트 및 통합 테스트 실행, 정적 분석, 성능 측정, 소스 코드 문서 추출 등이 포함된다. 이는 소프트웨어 품질을 높이고, 제품 출시를 앞당기는 것을 목표로 한다.

4. 1. 코드 통합

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

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

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

지속적 통합은 버전 관리 시스템이 원자적 커밋을 지원해야 한다. 즉, 개발자의 모든 변경 사항은 단일 커밋으로 처리된다.[17] 통합 브랜치에 병합하지 않고 브랜치에서 개발이 오래 지속될수록, 개발자 브랜치가 결국 다시 병합될 때 여러 통합 충돌[13] 및 실패의 위험이 커진다.

결국, 저장소는 개발자의 기준선과 너무 달라져서, 때때로 "병합 지옥" 또는 "통합 지옥"[14]이라고 불리는 상황에 들어갈 수 있으며, 여기서 통합하는 데 걸리는 시간이 원래 변경 사항을 만드는 데 걸린 시간을 초과한다.[15]

CI 지지자들은 빌드에 필요한 모든 파일과 정보를 버전 관리(Git의 경우 '저장소')에 저장할 것을 권장하며, 시스템은 새롭게 체크아웃된 상태에서 빌드 가능해야 하고 추가적인 의존성이 필요하지 않아야 한다.

마틴 파울러는 모든 개발자가 동일한 통합 브랜치에 커밋할 것을 권장한다.[16] 개발자는 변경 사항을 서로 자주 동기화하여 충돌하는 변경 사항을 해결하는 노력을 줄일 수 있다. 최소한 매일 동기화해야 하며, 하루에 한 번 이상 통합(커밋)하는 것이 좋은 관행으로 간주되며, 더 자주 하는 것이 좋다.[17]

4. 2. 자동화된 빌드

빌드 자동화는 모범 사례이다.[11][12]

빌드 자동화 도구는 빌드 과정을 자동화하며, CI 옹호자들은 단일 명령어로 시스템을 빌드할 수 있어야 한다고 권장한다.

자동화에는 통합 자동화가 포함되는 경우가 많으며, 여기에는 프로덕션과 유사한 배포 환경으로의 소프트웨어 배포가 포함된다. 많은 경우 빌드 스크립트는 바이너리를 컴파일할 뿐만 아니라, 문서, 웹사이트 페이지, 통계 및 배포 미디어(예: 데비안 DEB 파일, 레드햇 RPM 또는 윈도우즈 MSI 파일)도 생성한다. 빌드 서버는 정기적으로 또는 커밋 후에 코드를 컴파일하고 그 결과를 개발자에게 보고한다. 빌드 서버의 사용은 XP 커뮤니티 외부에서도 도입되었으며, 많은 조직이 XP의 모든 것을 채택하지 않고도 CI를 채택하고 있다.

4. 3. 자동화된 테스트

지속적 통합(CI)은 테스트 주도 개발(TDD) 방식에 따라 작성된 자동화된 단위 테스트와 함께 사용하도록 설계되었다. 개발자는 메인라인에 커밋하기 전에 로컬 환경에서 모든 단위 테스트를 실행하고 통과시켜야 한다. 이를 통해 한 개발자의 작업이 다른 개발자의 복사본을 손상시키는 것을 방지할 수 있다.[10] 부분적으로 완성된 기능은 기능 토글 등을 사용하여 커밋 전에 비활성화할 수 있다.

자동화된 유닛 테스트 외에도, CI를 사용하는 조직은 일반적으로 빌드 서버를 사용하여 품질 관리를 지속적으로 적용한다. 이러한 프로세스에는 유닛 테스트 및 통합 테스트 실행 외에도, 추가적인 정적 분석, 성능 측정 및 프로파일링, 소스 코드로부터의 문서 추출 및 포맷, 수동 QA 프로세스 촉진 등이 포함된다. 오픈 소스용으로 인기 있는 Travis CI 서비스에서는 CI 작업의 58.64%만 테스트를 실행하고 있다.[32]

이러한 품질 관리의 지속적인 적용은 모든 개발이 완료된 후에 품질 관리를 적용하는 전통적인 관행을 대신하여, 소프트웨어의 품질을 향상시키고 납품 시간을 단축하는 것을 목표로 한다. 이는 통합을 더 쉽게 하기 위해 더 자주 통합한다는 QA 프로세스의 원래 생각과 매우 유사하다.

4. 4. 지속적 전달 및 배포

지속적 전달은 통합 브랜치에 체크인된 소프트웨어가 항상 사용자에게 배포할 수 있는 상태임을 보장하며,[10] 지속적 배포는 배포 프로세스를 자동화한다.[18][19] ''지속적 전달''과 ''지속적 배포''는 종종 CI와 함께 수행되며 함께 CI/CD 파이프라인을 형성한다.

대부분의 CI 시스템은 빌드가 완료된 후 스크립트 실행을 허용한다. 대부분의 경우, 모든 사람이 볼 수 있는 라이브 테스트 서버에 애플리케이션을 배포하는 스크립트를 작성하는 것이 가능하다. 이러한 사고 방식의 더 나아간 발전은 지속적 배포이며, 이는 종종 결함이나 회귀를 방지하기 위한 추가 자동화를 통해 소프트웨어를 직접 프로덕션 환경에 배포하는 것을 요구한다.

CI는 CI/CD 파이프라인 내에서 지속적 전달과 연계되는 경우가 많다. CI는 메인 라인에 체크인된 소프트웨어를 항상 사용자에게 배포 가능한 상태로 만들고, CD는 배포 작업을 완전히 자동화한다.

5. 관련 사례

IMVU는 린 소프트웨어 개발 방법론을 적용하여 지속적 배포 시스템을 구축한 대표적인 사례이다.[9]

6. 도구


  • 아파치 컨티넘
  • 아파치 검프
  • 오토메이티드QA
  • 애틀라시안 밤부
  • [https://www.bitrise.io/ Bitrise]
  • 빌드봇
  • 빌드하이브
  • 빌드마스터
  • 캐비
  • 캐스케이드
  • 써클CI
  • 코드비머
  • 크루즈컨트롤
  • 크루즈컨트롤.rb
  • 일렉트릭 클라우드
  • 파이널빌더
  • 깃랩
  • 깃허브 액션
  • 허드슨
  • 젠킨스
  • 래셔널 팀 컨서트
  • 래셔널 소프트웨어 SCLM
  • 팀 파운데이션 서버
  • 시퍼블
  • [http://strider-cd.github.io/ 스트라이더]
  • 팀시티
  • Thoughtworks
  • 틴더박스
  • 트래비스 CI
  • Xcode

7. 장점 및 위험 요소

지속적 통합(CI)은 코드 품질 향상, 개발 시간 단축, 협업 증진, 위험 감소 등 여러 장점을 제공하지만, 몇 가지 위험 요소도 고려해야 한다.
장점:


  • 버그 발견 및 해결 용이: 버그를 조기에 발견하고 수정하기 쉽다.[5]
  • 통합 문제 감소: 여러 개발자의 코드 변경 사항을 통합할 때 발생하는 문제를 줄여준다.
  • 변경 사항 손실 최소화: 테스트 실패 시 롤백으로 인한 변경 사항 손실이 적다.
  • 최신 빌드 상시 이용: 테스트 및 배포를 위한 최신 빌드를 항상 사용할 수 있다.
  • 모듈식 코드 작성 유도: 작은 단위의 코드 변경을 자주 수행하므로, 자연스럽게 모듈화된 코드를 작성하게 된다.[20]
  • 빠른 피드백: 코드 변경이 시스템에 미치는 영향에 대한 피드백을 빠르게 받을 수 있다.
  • 소프트웨어 메트릭 수집: 코드 커버리지, 코드 복잡도 등의 소프트웨어 메트릭을 쉽게 수집할 수 있다.
  • 프로젝트 시간 및 비용 절약: 통합 문제를 조기에 발견하여 프로젝트 전체의 시간과 비용을 절약할 수 있다.

위험 요소:

  • 초기 빌드 시스템 구축 비용이 발생한다.[21]
  • 자동화된 테스트 스위트(Test Suite)를 만들고 유지 관리하는 데 노력이 필요하다.
  • 테스트 품질에 따라 지속적 통합의 효과가 달라진다.[22]
  • 빌드 시간이 길어지면 지속적 통합의 가치가 떨어진다.[22]
  • 불완전한 코드를 통합하지 않는 원칙은 일부 개발 방식과 맞지 않을 수 있다.[22]
  • DO-178C, ISO 26262와 같은 안전 필수 시스템 개발 표준을 준수하기 어려울 수 있다.

7. 1. 장점

지속적 통합(CI)은 코드 품질을 향상시키고, 개발 시간을 단축하며, 협업을 증진하고, 위험을 감소시키는 여러 장점을 제공한다. 주요 장점은 다음과 같다.

  • 버그 발견 및 해결 용이: 버그를 더 빨리 찾고 해결할 수 있다.[5] 지속적 통합 테스트에 실패하면, 마지막으로 성공한 빌드 이후의 변경 사항에서 원인을 찾을 수 있다. 각 변경 후 빌드를 진행하여, 변경 사항 하나하나가 원인이 된다.[5]
  • 통합 문제 감소: 여러 변경 사항을 통합할 때 발생할 수 있는 혼란을 방지하여, 릴리스 시점의 혼란을 피할 수 있다.
  • 변경 사항 손실 최소화: 테스트 실패 또는 버그 발견 시, 코드베이스를 정상 상태로 되돌릴 경우, 손실되는 변경 사항이 적다.
  • 최신 빌드 상시 이용: 테스트, 데모 및 릴리스를 위해 잘 알려진 빌드를 자주 사용할 수 있다.
  • 모듈식 코드 작성 유도: 잦은 코드 커밋은 모듈식의 덜 복잡한 코드를 작성하도록 유도한다.[20]
  • 빠른 피드백: 코드 변경이 시스템 전체에 미치는 영향에 대한 빠른 피드백을 제공한다.
  • 소프트웨어 메트릭 수집: 코드 커버리지, 코드 복잡도와 같은 소프트웨어 메트릭 수집을 지원한다.
  • 프로젝트 시간 및 비용 절약: 통합 버그는 조기에 발견되며, 작은 변경 세트이므로 추적이 용이해진다. 이로 인해 프로젝트의 라이프 사이클 전반에 걸쳐 시간과 비용을 절약할 수 있다.

7. 2. 위험 요소


  • 빌드 시스템 설정에 초기 투자 비용이 필요하다.[21]
  • 자동화된 테스트 스위트(Test Suite) 작성 및 유지 관리에 노력이 필요하다.
  • 부가 가치는 테스트의 품질에 따라 달라진다.[22]
  • 높은 빌드 지연 시간(대기열에 있음)은 가치를 제한한다.[22]
  • 불완전한 코드는 통합하지 않아야 함을 의미하며, 이는 일부 개발자가 선호하는 방식과 상반된다.[22]
  • 안전 및 미션 크리티컬 개발 보증(예: DO-178C, ISO 26262)은 달성하기 어려울 수 있는 문서화 및 검토가 필요하다.

8. 클라우드 환경에서의 모범 사례


  • '''파이프라인 수''': 소규모 팀은 하나의 저장소와 하나의 파이프라인을 갖는 것이 더 생산적일 수 있다. 반면, 대규모 조직은 각 팀별로 별도의 저장소와 파이프라인을 갖거나, 심지어 팀 내 각 서비스별로 별도의 저장소와 파이프라인을 가질 수 있다.
  • '''권한''': CI/CD 파이프라인 관련 권한의 맥락에서 최소 권한의 원칙을 준수하는 것은 소프트웨어 아키텍처의 동적 특성 때문에 어려울 수 있다. 관리자는 피해 범위를 최소화하기 위해 보완적인 보안 제어를 구현하면서 더 허용적인 권한을 선택할 수 있다.

참조

[1] 서적 Object Oriented Design: With Applications https://books.google[...] Benjamin Cummings 2014-08-18
[2] 간행물 Embracing change with extreme programming 1999
[3] conference Infuse: fusing integration test management with change management
[4] 서적 Object-Oriented Analysis and Design with applications http://www.cvauni.ed[...] 1998-12
[5] 웹사이트 Continuous Integration http://martinfowler.[...] 2014-01-09
[6] conference Extreme Programming: A Humanistic Discipline of Software Development https://books.google[...] Springer Science+Business Media 1998-03-28
[7] 서적 Extreme Programming Explained https://archive.org/[...] Addison-Wesley Professional
[8] 뉴스 A Brief History of DevOps, Part III: Automated Testing and Continuous Integration https://circleci.com[...] 2018-05-19
[9] 간행물 2021 Sixth International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET)
[10] 웹사이트 Continuous integration https://www.atlassia[...]
[11] 간행물 "[OSLC] Possible new Working Group – Automation" http://open-services[...] 2010-02-16
[12] blog Rails Deployment and Automation with ShadowPuppet and Capistrano http://blog.railsmac[...] 2010-02-16
[13] 서적 Continuous Integration. Improving Software Quality and Reducing Risk Addison-Wesley
[14] 웹사이트 Integration Hell http://c2.com/cgi/wi[...] 2009-09-19
[15] 웹사이트 What is Continuous Integration? https://aws.amazon.c[...]
[16] article Practices http://martinfowler.[...] 2015-11-29
[17] 서적 Continuous Integration: Improving Software Quality and Reducing Risk Addison-Wesley Professional 2007
[18] 웹사이트 Continuous deployment in 5 easy steps http://radar.oreilly[...] O’Reilly 2013-01-10
[19] 웹사이트 Continuous Deployment at IMVU: Doing the impossible fifty times a day http://timothyfitz.w[...] Wordpress 2013-01-10
[20] 간행물 An Empirical Study on the Impact of Code Contributor on Code Smell https://qrs20.techco[...] 2020-07
[21] 간행물 Problems, causes and solutions when adopting continuous delivery—A systematic literature review
[22] 웹사이트 Assessing challenges of continuous integration in the context of software requirements breakdown: a case study http://publications.[...]
[23] 서적 Serverless Architectures on AWS Manning
[24] 서적 Pipeline as Code Continuous Delivery with Jenkins, Kubernetes, and Terraform Manning
[25] 서적 Continuous Delivery Reliable Software Releases Through Build, Test, and Deployment Automation
[26] 웹사이트 Continuous Integration http://martinfowler.[...] 2014-01-09
[27] 서적 Object Oriented Design: With Applications https://books.google[...] Benjamin Cummings 2014-08-18
[28] 간행물 Embracing change with extreme programming 1999
[29] 서적 Continuous Integration. Improving Software Quality and Reducing Risk Addison-Wesley
[30] 웹사이트 Integration Hell http://c2.com/cgi/wi[...] 2009-09-19
[31] 웹사이트 継続的インテグレーションとは? https://aws.amazon.c[...] 2021-01-10
[32] 간행물 An Analysis of 35+ Million Jobs of Travis CI IEEE 2019
[33] 웹인용 Integration Hell http://c2.com/cgi/wi[...] 2009-09-19


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com