좋은 CI 구축 프로세스란 무엇입니까?

https://stackoverflow.com/questions/102902

01-07-2019
|

문제

좋은 CI 구축 프로세스를 구성하는 것은 무엇입니까?

우리는 CI를 사용하지만 배포해야 하는 여러 서비스에 대한 종속성이 있고 다른 앱도 이에 종속될 수 있는 경우 현실적인 CI 목표라도 프로덕션에 배포합니다.

QA로 자동화되고 거기서부터 수동으로 진행되면 좋은 CI 구축 프로세스가 충분히 좋은가요?

해결책

"상황에 따라 다릅니다" :)

우리는 CI 시스템을 사용하여 다음을 수행합니다.

빌드 및 단위 테스트
단일 상자에 배포, 통합 테스트 및 코드 분석 실행
연구실 환경에 배포
프로덕션과 유사한 시스템에서 승인 테스트 실행
프로덕션 배포를 위한 코드 드롭으로 전달되는 드롭 빌드

이는 20개 이상의 서버에 배포된 약 12개의 서비스와 데이터베이스로 구성된 신규 프로젝트를 위한 것이며, 이 프로젝트는 6개의 다른 '외부' 서비스에도 종속되어 있습니다.

현실적인 목표로 CI 도구를 사용하여 제품을 프로덕션 환경에 배포하시겠습니까?다시..."때에 따라 다르지"

왜 이런 일을 하고 싶나요?

프로세스가 있으면 변경 사항을 더 빠르고 자주 롤백할 수 있습니다.
인적 오류 가능성 감소
프로덕션으로 이동하기 전에 테스트 환경에서 동일한 배포 전략을 테스트하고 문제를 더 일찍 발견할 수 있습니다.

이 질문에 대답하기 전에 해결해야 할 몇 가지 기술적인 사항은 다음과 같습니다.

시스템의 가동 시간 요구 사항은 무엇입니까? 가동 중지 시간이 허용됩니까, 아니면 연중무휴로 가동되어야 합니까?
사람의 개입/승인이 필요한 변경 제어 프로세스가 마련되어 있습니까?
배포가 실패할 경우 모든 구성 요소가 알려진 양호한 상태로 롤백될 수 있을 만큼 배포가 강력합니까?
귀하의 시스템은 하나 이상의 구성 요소 배포가 실패하는 경우(그리고 마지막으로 알려진 양호한 상태로 위의 롤백이 있는 경우) 다양한 버전의 서비스 또는 클라이언트를 처리하도록 설계되었습니까?
구성 요소가 종속성/클라이언트의 혼합 버전을 처리할 수 없는 부분 배포를 처리할 수 있는 스마트한 프로세스가 있습니까?
데이터베이스 배포/업그레이드는 어떻게 처리하고 있나요?
언제 문제가 발생하는지 알 수 있도록 모니터링 기능이 마련되어 있나요?

다음은 최근 관련 링크입니다. 오토메이션 그리고 필요한 도구 만들기.

시스템이 복잡해질수록 모든 것을 자동화하는 것이 더 어려워지지만 이것이 가치 있는 목표가 아니라는 의미는 아니며, 이를 완료하려면 훨씬 더 많은 노력과 의지가 필요할 뿐입니다. 당신이 직면하게 될 어려움, 설명해야 할 문제(실패) ~ 할 것이다 발생), 인프라 구축의 정치적 과제(vs.더 많은 제품 기능).

이제 여기에 큰 비밀이 있습니다.기술적 과제는 어렵지만 불가능하지는 않습니다.그만큼 정치적인 도전은 극복할 수 없을 수도 있습니다.개발 시간이든 타사 솔루션 구입이든 이에 관한 모든 것은 비용이 듭니다.그렇다면 실제로 $1,000, $10,000, $100,000 또는 $1M 솔루션을 구축할 수 있습니까?

어떤 솔루션을 선택하든 먼저 자동화가 견고한지 확인하고 두 번째로 완벽한지 확인하세요.즉.프로덕션에 배포하는 취약한 솔루션이 아닌 테스트 환경에 배포하기 위해 가능한 한 강력한 솔루션이 있는지 확인하십시오.

다른 팁

CI는 배포 메커니즘으로 사용되지 않습니다.그것 ~이다 CI가 QA/테스트 서버에 자동 배포를 실행하여 빌드 작업의 이러한 측면을 보장하도록 하는 것은 좋지만 배포 수단으로 Cruise Control 또는 Bamboo와 같은 CI 시스템을 사용하지는 않습니다.

CI는 자동 테스트 실행, 정적 분석을 통한 코드베이스 확인 및 기타 해당 특성 검사를 자동화하기 위해 정기적으로 코드베이스를 구축하기 위한 것입니다.

CI 빌드의 기본 개념을 이해해야 합니다.CI는 지속적인 통합(Continuous Integration)을 의미하며 CI 빌드는 개발자가 소스 제어 시스템에 코드를 체크인할 때(또는 특정 간격으로) 최신 변경 사항이 코드 베이스를 손상시키지 않도록 하기 위해 수행되는 일회용 빌드입니다. (따라서 변경 사항을 코드 베이스에 지속적으로 통합한다는 아이디어)

이를 위해 실제 빌드 서버 프로세스에 사용되는 기술은 빌드 중에 실제로 일어나는 일과 크게 관련이 없습니다.@pdavis가 언급했듯이 CI 빌드는 코드 베이스를 컴파일하고, 일부 코드 분석(FxCop, StyleCop, Lint 등)을 실행하고, 단위 테스트 및 코드 적용 범위를 실행하고, 개념에 영향을 미치는 수행하려는 기타 사용자 정의 분석을 실행해야 합니다. "성공" 또는 "실패" 빌드의 결과입니다.

CI 빌드를 환경에 자동으로 배포하는 것은 실제로 빌드 서버의 제어에 속하지 않습니다.즉, 특정 조건(예: 빌드가 성공적으로 완료됨)을 감지하면 배포를 처리하는 빌드 서버에서 실행되는 별도의 프로젝트를 언제든지 만들 수 있지만 이는 항상 완전히 독립적인 작업으로 수행되어야 합니다.

저는 직장에서 정말 기대되는 새로운 프로젝트를 시작하고 있습니다.우리는 아직 초기 설계 단계에 있으며 최근에 논리 시스템 아키텍처를 완료했습니다.테스트 및 스테이징 환경을 위한 새 서버를 주문했으며 Cruise Control(Cruise Control 기반의 CI) 구축 시스템을 설정하고 있습니다.http://cruisecontrol.sourceforge.net/) 및 MSBuild(http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx) 이는 기본적으로 ANT의 향상된 포트입니다.이제 Visual Studio 2005 프로젝트와 솔루션 파일이 모두 MSBuild 형식인 것 같습니다.Cruise Control은 자동으로 Visual Source Safe(Subversion은 아니지만 처리할 수 있음)에서 소스를 가져와서 컴파일한 다음 fxCop을 통해 실행합니다(http://www.gotdotnet.com/Team/FxCop/), n단위(http://www.nunit.org/), n커버(http://ncover.org/site/), 마지막이지만 임대는 아닌 유인원(http://www.redhillconsulting.com.au/products/simian/).Cruise Control은 다양한 도구에서 컴파일된 결과를 모두 표시할 수 있는 매우 훌륭한 웹 사이트 인터페이스를 갖추고 있으며 한 빌드에서 다음 빌드까지의 코드 변경 사항도 표시할 수 있습니다.또한 빌드 기록의 모든 빌드를 추적합니다.저는 테스트 중심 개발을 기대하고 있으며 nUnit/nCover와 결합된 이러한 유형의 접근 방식이 우리가 아무것도 손상시키지 않은 변경 사항을 출시하기 전에 꽤 좋은 아이디어를 제공할 것이라고 생각합니다.프로젝트가 충분히 진행되면 자동화된 사용자 인터페이스 테스트 유형을 통합할 계획도 있습니다.도구에 따라 이는 빌드 서버에 도구를 설치하고 Cruise Control에서 호출하기만 하면 됩니다.달콤한.

좋은 CI 프로세스는 전체 또는 거의 전체 단위 테스트 범위를 갖습니다.단위 테스트 테스트 클래스 및 메서드 vs.시스템의 여러 부분을 테스트하는 통합 테스트.CI 빌드를 설정할 때 단위 테스트를 자동화하도록 하세요.이렇게 하면 CI 빌드가 하루에 여러 번 실행될 수 있습니다.우리는 2시간마다 실행되도록 설정했습니다.

하루에 한 번 실행되는 장기 실행 빌드를 가질 수 있습니다.이들은 다른 서비스를 사용하고 통합 테스트를 실행할 수 있습니다.

저는 ThoughtWorks 프리젠테이션(Cruise Control 제작자)을 보고 있었는데 그들은 실제로 이 문제를 다루었습니다.그들의 대답은 배포가 테스트하기에는 너무 복잡하다는 것입니다.왜?그렇지 않으면 고객이 테스터가 되는데, 이는 바로 여러분이 원하지 않는 상황입니다.

배포 구조가 복잡한 경우 시각화 서버를 설정하세요.대화해야 하는 모든 시스템인 척 하십시오.깨끗한 이미지로 재설정할 수 있으므로 항상 알려진 양호한 상태에서 시작할 수 있습니다.

초기 질문에 답하려면 저장소와 개발자 간의 의사소통을 가능하게 하는 프로세스가 좋은 프로세스입니다.저장소의 상태가 좋지 않은 경우(컴파일되지 않는 코드, 테스트 실패 등) 개발자는 이를 수정할 수 있도록 가능한 한 빨리 이를 알게 됩니다.

버그가 나중에 발견될수록 수정 비용이 더 많이 듭니다.따라서 버그는 가능한 한 빨리 발견되어야 합니다.이것이 CI의 동기입니다.

좋은 CI는 가능한 한 많은 버그를 잡아야 합니다.전체 애플리케이션은 코드(종종 여러 언어로 제공됨), 데이터베이스 스키마, 배포 파일 등으로 구성됩니다.이들 중 하나라도 오류가 발생하면 버그가 발생할 수 있으므로 CI는 가능한 한 많은 오류를 실행해야 합니다.

CI는 적절한 QA 규율을 대체하지 않습니다.또한 프로젝트 첫날에는 CI가 매우 포괄적일 필요는 없습니다.처음에 기본 컴파일 및 단위 테스트를 수행하는 간단한 CI 프로세스로 시작할 수 있습니다.QA에서 더 많은 종류의 버그를 발견하면 향후 해당 버그가 발생할 수 있도록 CI 프로세스를 조정해야 합니다.또한 정적 코드 분석 검사가 포함될 수 있으므로 코드베이스 전반에 걸쳐 일관된 코딩 및 디자인 이상을 구현할 수 있습니다.

QA로 자동화되고 거기서부터 수동으로 진행되면 좋은 CI 구축 프로세스가 충분히 좋은가요?

내 생각에 "수동" 배포는 배포 엔지니어 역할을 맡은 사람이 배포 후 문제가 발생할 수 있다는 두려움이 있을 때 사용되는 것 같습니다.그는 배포 도구의 신뢰성과 안정성에 자신이 없습니다.

이 기능은 프로덕션 환경에서 자동화된 배포 프로세스 테스트를 통해 사라질 수 있습니다. 또한 배포 후 롤백 메커니즘을 테스트해야 합니다.

이 기능을 충분히 테스트하면 사용하는 프로세스와 도구에 대한 자신감을 얻게 됩니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow