2018.05.02

CI/CD 시작하기 : CI/CD 파이프라인으로 애플리케이션 딜리버리 자동화

Isaac Sacolick | InfoWorld

CI/CD는 애플리케이션 통합 및 딜리버리 단계를 자동화하고 애플리케이션 구성을 표준화한다. 조직에서 CI/CD를 사용하는 방법을 알아보자.

건설 현장 옆을 지나가다 보면 여러 가지 유형의 작업을 볼 수 있다. 기반 공사, 프레임, 인테리어 등 실제 건축물을 짓는 작업이 있고, 크레인, 작업자용 엘리베이터, 비계 및 기타 안전 구조물 설치 등 건설이 가능하도록 지원하는 작업도 있다.

애플리케이션 개발도 비슷하다. 데이터베이스, 애플리케이션, 사용자 인터페이스를 개발하기 위해 필요한 작업이 있고, 건설과 마찬가지로 생산적이고 안정적인 고품질의 소프트웨어를 개발하고 전달하기 위한 툴 및 작업 방식에 대한 투자도 있다.



이러한 작업 방식은 데브옵스의 일부이며, 지속적 통합과 지속적 전달(Continuous Integration and Continuous Delivery, CI/CD)은 촉박한 일정에서 고품질의 소프트웨어를 제공하기 위한 기반이 되는 방식이다.

CI/CD 파이프라인 및 작업 방식으로 생산성, 품질, 속도 향상
CI/CD는 애플리케이션 통합과 딜리버리 단계를 자동화하고 애플리케이션 구성을 표준화한다. 개발자가 새 코드를 체크인하면, CI/CD 파이프라인이 빌드, 테스트, 데이터 마이그레이션, 애플리케이션 배포, 서비스 호출 및 기타 스크립트화된 절차에 따라 대상 환경에서 코드 변경을 실행한다. 팀은 이러한 자동화를 통해 작업 방식을 조정해서 코드를 체크인하고 더 빈번하게 애플리케이션을 통합, 테스트, 제공한다.

완전한 성숙 단계까지 간 조직은 한 걸음 더 나아가 프로덕션 환경에 지속적 배포를 구현한다. 그러나 기업 및 제품 유형에 따라 이러한 지속적 배포가 최적의 방법이 아닐 수도 있다.

549명의 소프트웨어 전문가를 대상으로 한 최근 설문 결과에서 CI/CD 파이프라인과 함께 데브옵스를 실천하는 성숙한 조직이 얻는 이점을 알 수 있다. 응답자의 60%는 새 코드를 7일 이내에 프로덕션에 구현할 수 있다고 답했으며, 약 40%는 24시간 이내에 배포가 가능하다고 답했다. 응답자의 약 50%는 프로덕션 문제 발생 시 평균 서비스 복원 시간이 2시간 미만이라고 답했다.

CI/CD를 실천하면 개발, 테스트, 운영 모범 사례에 팀을 맞춤으로써 다음과 같은 실질적 혜택도 얻을 수 있다.

- 변경 사항을 자주 푸시하고자 하는 개발자와 안정적인 애플리케이션을 원하는 운영 담당자 사이의 마찰을 해결한다.
- 코드 변경을 사용자에게 푸시하기 전에 검증하기 위해 개발 팀은 지속적인 테스트를 실행해야 한다.
- 큰 변경보다 안정적으로 통합 및 테스트가 가능한 더 작은 규모의 증분적 코드 변경을 수행하도록 개발자를 독려한다.
- 새로운 기능을 위한 더 넓은 범위의 개발 작업을 수행하는 동시에 신속한 수정 요청까지 받는 팀에 작업의 유연성을 부여한다.
- 기능, 성능 및 데이터 중심 테스트를 더 많이 실행해서 더 높은 품질의 애플리케이션을 제공하고 프로덕션 결함을 줄일 수 있게 해준다.

지속적 통합(CI)은 개발 생산성과 품질 향상의 원동력
예를 들어 기존 애플리케이션의 업그레이드 작업을 진행 중이라고 하자. 팀은 새로운 기능을 개발하고 사용자가 보고한 이런저런 문제를 수정하고 기반 코드 라이브러리 업그레이드에 따른 기술적 부채(technical debt)를 해결하고 자주 사용되는 몇몇 보고서의 성능을 개선해야 한다. 팀은 애플리케이션 개발자와 데이터베이스 개발자, 보고서 작성자, 테스터, 시스템 엔지니어로 구성된다. 스크럼 개발 프로세스에 따르며, 이미 깃(Git) 리포지토리에 애플리케이션 코드를 두고 있다.

그러나 지난 릴리즈에서 몇 가지가 제대로 작동하지 않았다. 우선 대부분의 테스트를 수동으로 진행했기 때문에 애플리케이션을 테스트하는 데 며칠이 소요됐다. 테스트가 완료된 시점에는 그 개발 주기가 마무리될 때까지 수정해야 하는 상당한 양의 결함 목록이 작성됐다. 버그 수정 주기 이후 긴 수동 테스트 작업이 이어지자 팀은 릴리즈를 늦출 수밖에 없었다. 배포한 다음에는 애플리케이션과 데이터베이스의 변경이 제대로 동기화되지 않은 탓에 프로덕션 문제가 발생했다.

이번에는 같은 실수를 되풀이하지 않기로 다짐하고, 비즈니스 및 IT 리더와 지속적 통합 방식을 구현하기로 합의한다. 결과적으로 릴리즈와 관련된 우선 순위와 개발 방식도 그에 맞춰 바뀐다.

회귀 테스트 및 기타 지속적 테스트를 도입하지 않고는 지속적 통합 방식을 구축할 수 없다. 따라서 필요한 변경을 위한 코드 작업에 뛰어들기 전에 전체 팀이 테스터와 협력해서 빌드의 유효성을 확인하는, 가장 중요한 테스트를 자동화한다. 이 작업이 완료되면 중요한 단위 및 기능 테스트를 수행할 수 있는 여러 툴과 스크립트가 마련된다.

다음으로 살펴보는 부분은 애플리케이션 빌드에 사용되는 툴이다. 스크립트는 애플리케이션에서는 작동하지만 실패한 빌드의 오류 조건은 매끄럽게 처리하지 못한다. 또한 데이터베이스 변경을 푸시하고 롤백하기 위한 프로세스가 없기 때문에 기본적인 프로세스를 하나 만든다. 모든 빌드 및 테스트 스크립트를 하나의 자동화된 프로세스로 배열하는 데 사용되는 지속적 통합 툴을 선택하고, 이를 깃에 연결해서 코드가 병합될 때 빌드가 트리거되도록 한다.

개발된 지속적 통합 툴과 자동화를 갖고 이제 개발 방식에 대해 팀과 논의한다. 단절된 상태에서 개발하고 릴리즈 주기가 끝날 때까지 기다렸다가 모든 요소가 제대로 돌아가는지 확인하는 방법은 더 이상 사용할 수 없다.

가장 먼저 하는 일은 매일 코드 변경을 커밋하도록 개발자들을 독려하는 것이다. 처음에는 개발자는 두려움을 느낄 수 있다. 코드가 기능적 상태여야 하고 빌드가 잘못되거나 테스트에 통과하지 못해 지속적 통합 프로세스가 실패하면 안 되기 때문이다. 팀은 곧 전체 기능을 개발하거나 복잡한 리팩터링을 시도하기보다는 바이트 단위의 코드로 작업해야 한다는 점을 깨닫게 된다.

또한 팀은 테스트를 통해 변경된 기능이 검증되고 지속적 테스트 프로세스에 테스트를 통합할 수 있어야만 개발이 “완료”된 것으로 간주된다는 데 동의한다. 따라서 팀은 테스터가 테스트를 수행하기에 충분한 시간을 확보할 수 있도록 스프린트 중 시간을 관리하는 방법을 재고해야 한다. 팀은 새 기능을 코딩하기 전에 단위 테스트를 개발하는 테스트 중심 개발 방법론을 가장 잘 적용할 방법을 논의한다.



2018.05.02

CI/CD 시작하기 : CI/CD 파이프라인으로 애플리케이션 딜리버리 자동화

Isaac Sacolick | InfoWorld

CI/CD는 애플리케이션 통합 및 딜리버리 단계를 자동화하고 애플리케이션 구성을 표준화한다. 조직에서 CI/CD를 사용하는 방법을 알아보자.

건설 현장 옆을 지나가다 보면 여러 가지 유형의 작업을 볼 수 있다. 기반 공사, 프레임, 인테리어 등 실제 건축물을 짓는 작업이 있고, 크레인, 작업자용 엘리베이터, 비계 및 기타 안전 구조물 설치 등 건설이 가능하도록 지원하는 작업도 있다.

애플리케이션 개발도 비슷하다. 데이터베이스, 애플리케이션, 사용자 인터페이스를 개발하기 위해 필요한 작업이 있고, 건설과 마찬가지로 생산적이고 안정적인 고품질의 소프트웨어를 개발하고 전달하기 위한 툴 및 작업 방식에 대한 투자도 있다.



이러한 작업 방식은 데브옵스의 일부이며, 지속적 통합과 지속적 전달(Continuous Integration and Continuous Delivery, CI/CD)은 촉박한 일정에서 고품질의 소프트웨어를 제공하기 위한 기반이 되는 방식이다.

CI/CD 파이프라인 및 작업 방식으로 생산성, 품질, 속도 향상
CI/CD는 애플리케이션 통합과 딜리버리 단계를 자동화하고 애플리케이션 구성을 표준화한다. 개발자가 새 코드를 체크인하면, CI/CD 파이프라인이 빌드, 테스트, 데이터 마이그레이션, 애플리케이션 배포, 서비스 호출 및 기타 스크립트화된 절차에 따라 대상 환경에서 코드 변경을 실행한다. 팀은 이러한 자동화를 통해 작업 방식을 조정해서 코드를 체크인하고 더 빈번하게 애플리케이션을 통합, 테스트, 제공한다.

완전한 성숙 단계까지 간 조직은 한 걸음 더 나아가 프로덕션 환경에 지속적 배포를 구현한다. 그러나 기업 및 제품 유형에 따라 이러한 지속적 배포가 최적의 방법이 아닐 수도 있다.

549명의 소프트웨어 전문가를 대상으로 한 최근 설문 결과에서 CI/CD 파이프라인과 함께 데브옵스를 실천하는 성숙한 조직이 얻는 이점을 알 수 있다. 응답자의 60%는 새 코드를 7일 이내에 프로덕션에 구현할 수 있다고 답했으며, 약 40%는 24시간 이내에 배포가 가능하다고 답했다. 응답자의 약 50%는 프로덕션 문제 발생 시 평균 서비스 복원 시간이 2시간 미만이라고 답했다.

CI/CD를 실천하면 개발, 테스트, 운영 모범 사례에 팀을 맞춤으로써 다음과 같은 실질적 혜택도 얻을 수 있다.

- 변경 사항을 자주 푸시하고자 하는 개발자와 안정적인 애플리케이션을 원하는 운영 담당자 사이의 마찰을 해결한다.
- 코드 변경을 사용자에게 푸시하기 전에 검증하기 위해 개발 팀은 지속적인 테스트를 실행해야 한다.
- 큰 변경보다 안정적으로 통합 및 테스트가 가능한 더 작은 규모의 증분적 코드 변경을 수행하도록 개발자를 독려한다.
- 새로운 기능을 위한 더 넓은 범위의 개발 작업을 수행하는 동시에 신속한 수정 요청까지 받는 팀에 작업의 유연성을 부여한다.
- 기능, 성능 및 데이터 중심 테스트를 더 많이 실행해서 더 높은 품질의 애플리케이션을 제공하고 프로덕션 결함을 줄일 수 있게 해준다.

지속적 통합(CI)은 개발 생산성과 품질 향상의 원동력
예를 들어 기존 애플리케이션의 업그레이드 작업을 진행 중이라고 하자. 팀은 새로운 기능을 개발하고 사용자가 보고한 이런저런 문제를 수정하고 기반 코드 라이브러리 업그레이드에 따른 기술적 부채(technical debt)를 해결하고 자주 사용되는 몇몇 보고서의 성능을 개선해야 한다. 팀은 애플리케이션 개발자와 데이터베이스 개발자, 보고서 작성자, 테스터, 시스템 엔지니어로 구성된다. 스크럼 개발 프로세스에 따르며, 이미 깃(Git) 리포지토리에 애플리케이션 코드를 두고 있다.

그러나 지난 릴리즈에서 몇 가지가 제대로 작동하지 않았다. 우선 대부분의 테스트를 수동으로 진행했기 때문에 애플리케이션을 테스트하는 데 며칠이 소요됐다. 테스트가 완료된 시점에는 그 개발 주기가 마무리될 때까지 수정해야 하는 상당한 양의 결함 목록이 작성됐다. 버그 수정 주기 이후 긴 수동 테스트 작업이 이어지자 팀은 릴리즈를 늦출 수밖에 없었다. 배포한 다음에는 애플리케이션과 데이터베이스의 변경이 제대로 동기화되지 않은 탓에 프로덕션 문제가 발생했다.

이번에는 같은 실수를 되풀이하지 않기로 다짐하고, 비즈니스 및 IT 리더와 지속적 통합 방식을 구현하기로 합의한다. 결과적으로 릴리즈와 관련된 우선 순위와 개발 방식도 그에 맞춰 바뀐다.

회귀 테스트 및 기타 지속적 테스트를 도입하지 않고는 지속적 통합 방식을 구축할 수 없다. 따라서 필요한 변경을 위한 코드 작업에 뛰어들기 전에 전체 팀이 테스터와 협력해서 빌드의 유효성을 확인하는, 가장 중요한 테스트를 자동화한다. 이 작업이 완료되면 중요한 단위 및 기능 테스트를 수행할 수 있는 여러 툴과 스크립트가 마련된다.

다음으로 살펴보는 부분은 애플리케이션 빌드에 사용되는 툴이다. 스크립트는 애플리케이션에서는 작동하지만 실패한 빌드의 오류 조건은 매끄럽게 처리하지 못한다. 또한 데이터베이스 변경을 푸시하고 롤백하기 위한 프로세스가 없기 때문에 기본적인 프로세스를 하나 만든다. 모든 빌드 및 테스트 스크립트를 하나의 자동화된 프로세스로 배열하는 데 사용되는 지속적 통합 툴을 선택하고, 이를 깃에 연결해서 코드가 병합될 때 빌드가 트리거되도록 한다.

개발된 지속적 통합 툴과 자동화를 갖고 이제 개발 방식에 대해 팀과 논의한다. 단절된 상태에서 개발하고 릴리즈 주기가 끝날 때까지 기다렸다가 모든 요소가 제대로 돌아가는지 확인하는 방법은 더 이상 사용할 수 없다.

가장 먼저 하는 일은 매일 코드 변경을 커밋하도록 개발자들을 독려하는 것이다. 처음에는 개발자는 두려움을 느낄 수 있다. 코드가 기능적 상태여야 하고 빌드가 잘못되거나 테스트에 통과하지 못해 지속적 통합 프로세스가 실패하면 안 되기 때문이다. 팀은 곧 전체 기능을 개발하거나 복잡한 리팩터링을 시도하기보다는 바이트 단위의 코드로 작업해야 한다는 점을 깨닫게 된다.

또한 팀은 테스트를 통해 변경된 기능이 검증되고 지속적 테스트 프로세스에 테스트를 통합할 수 있어야만 개발이 “완료”된 것으로 간주된다는 데 동의한다. 따라서 팀은 테스터가 테스트를 수행하기에 충분한 시간을 확보할 수 있도록 스프린트 중 시간을 관리하는 방법을 재고해야 한다. 팀은 새 기능을 코딩하기 전에 단위 테스트를 개발하는 테스트 중심 개발 방법론을 가장 잘 적용할 방법을 논의한다.



X