지속적인 통합 이전에 몇 명의 개발자가 우리에게 효과적입니까?

지속적인 통합과 관련된 오버 헤드가 있습니다 (예 : 설정, 재교육, 인식 활동, 데이터 문제로 판명되는 "버그"수정을위한 중지, 프로그래밍 스타일의 강제 분리 등).

지속적인 통합은 어떤 시점에서 비용을 지불합니까?

편집 : 이들은 나의 발견이었다

설정은 VSS 또는 TFS에서 읽은 Nant와 함께 CruiseControl.Net이었습니다.

다음은 설정과 관련이없는 몇 가지 실패 이유입니다.

조사 비용 : 코드, 데이터 품질 또는 인프라 문제 (예 : 네트워크 문제, 소스 제어에서 시간 초과 읽기, 타사 서버)와 같은 다른 소스에서 빨간색 표시등이 논리적으로 일관성이 없는지 여부를 조사하는 데 소요 된 시간 다운 등)

인프라에 대한 정치적 비용 : 테스트 실행의 각 방법에 대해 "인프라"검사를 수행하는 것을 고려했습니다. 빌드 서버를 교체하는 것 외에는 시간 초과에 대한 해결책이 없었습니다. 빨간 테이프가 방해를 받고 서버 교체가 없었습니다.

단위 테스트 수정 비용 : 데이터 품질 문제로 인한 빨간색 표시등은 잘못 작성된 단위 테스트의 지표 일 수 있습니다. 따라서 데이터 의존성 단위 테스트가 다시 작성되어 나쁜 데이터로 인한 적색 등의 가능성을 줄였습니다. 많은 경우, 단위 테스트를 정확하게 실행할 수 있도록 테스트 환경에 필요한 데이터가 삽입되었습니다. 데이터를보다 견고하게 만들면이 데이터에 의존하는 경우 테스트가 더욱 강력 해집니다. 물론 이것은 잘 작동했습니다!

적용 비용, 즉 기존 코드에 대한 단위 테스트 작성 : 단위 테스트 범위에 문제가있었습니다. 단위 테스트가없는 수천 가지 방법이있었습니다. 따라서이를 만들려면 상당한 양의 인력이 필요합니다. 이것이 비즈니스 사례를 제공하기에는 너무 어려울 것이기 때문에, 앞으로 새로운 공개 방법에 대해 단위 테스트를 사용하기로 결정했습니다. 단위 테스트가없는 것을 '잠재적 적외선'이라고합니다. 여기서 중요한 점은 정적 메소드가 특정 정적 메소드가 실패한 방법을 고유하게 판별하는 방법에있어 어려운 점이라는 점입니다.

맞춤형 출시 비용 : Nant 스크립트는 지금까지만 진행되었습니다. 예를 들어 EPiServer, CMS 또는 UI 지향 데이터베이스 배포를위한 CMS 종속 빌드에는 유용하지 않습니다.

시간별 테스트 실행 및 야간 QA 빌드를 위해 빌드 서버에서 발생한 문제 유형입니다. 필자는 빌드 마스터가 릴리스시, 특히 하나의 맨 밴드와 작은 빌드로 이러한 작업을 수동으로 수행 할 수 있기 때문에 이러한 작업이 필요하지 않다는 점을 기쁘게 생각합니다. 따라서 단일 단계 빌드는 내 경험에서 CI 사용을 정당화하지 못했습니다. 더 복잡한 다단계 빌드는 어떻습니까? 특히 Nant 스크립트가 없으면 빌드하기가 어려울 수 있습니다. 따라서 하나를 만들었더라도 더 이상 성공하지 못했습니다. 적색 등 문제를 해결하는 데 드는 비용이 이점을 능가했습니다. 결국 개발자는 관심을 잃고 홍등의 타당성에 의문을 제기했습니다.

공정한 시도를 한 결과 CI가 비싸고 단지 작업을 수행하는 대신 많은 노력을 기울이고 있다고 생각합니다. 경보 시스템을 도입하고 유지 관리하는 것보다 대규모 프로젝트를 엉망으로 만들지 않는 숙련 된 개발자를 고용하는 것이 더 비용 효율적입니다.

이러한 개발자가 떠나도 마찬가지입니다. 그가 따르는 프로세스는 요구 사양, 디자인 사양, 코딩 가이드 라인을 고수하고 코드를 읽을 수 있도록 코드에 주석을 달아야하기 때문에 좋은 개발자가 떠나더라도 문제가되지 않습니다. 이 모든 것이 검토됩니다. 이런 일이 일어나지 않으면 그의 팀 리더는 자신의 직무를 수행하지 않는 것입니다.

CI가 작동하기 위해서는 단위 테스트 만 작성하고, 전체 범위를 유지하고, 규모가 큰 시스템을위한 작동 인프라를 확보하는 것만으로는 충분하지 않습니다.

결론 : 릴리스 전에 많은 버그를 수정하는 것이 비즈니스 관점에서 바람직한 지 여부에 의문을 가질 수 있습니다. CI에는 고객이 UAT에서 식별하거나 보증 기간이 만료 될 때 고객 서비스 계약의 일부로 회사가 수리 비용을 지불 할 수있는 몇 가지 버그를 포착하기위한 많은 작업이 필요합니다.

CI 엔진 설정은 집에서 화재 경보를 설정하는 것과 유사합니다.

내 생각에 이점은 많은 개발자와 관련이 없지만 큰 코드 기반과 관련이 있습니다. CI 엔진은 당신이 원하지 않는 모든 지루한 작업을 적극적으로 수행하고 매번 수행합니다.

오랫동안 만지지 않은 원격 모듈을 분리하면 즉시 알려줍니다. 컴파일 테스트뿐만 아니라 단위 테스트를 설정 한 경우 기능적으로도 수행 할 수 있습니다.

또한 CI 엔진이 설치 프로그램 설정 등을 포함하여 모든 지루한 작업을 수행하도록 허용하는 경우 수동으로 수행하지 않아도됩니다. 소스를 체크인하고 표준 위치에서 완성 된 제품이 나올 때까지 기다릴 수 있습니다. (편집 : CI 엔진은 또한 명확한 환경에서 작동하여 개발자 별 설정을 피하고 재현성을 보장합니다)

이것은 또한 품질 보증의 일부입니다.

편집 : 위의 내용을 작성한 후 Java 용 Maven 빌드 도구에 대한 경험이 있습니다. 기본적으로이를 통해 프로젝트 내부에 완전한 CI 구성 (pom.xml 사용)을 유지하여 CI 설치를 유지 관리하거나 다른 CI 엔진으로 마이그레이션하는 것이 훨씬 간단 해집니다.

그것은 많은 개발자가 아니지만 1에서 n까지 (포함하는) 1에서 n까지 걸리는 단계 수는 ...

1 : 코드 확인
및
n : 설치 가능 / 배포 가능 패키지

N <2는 경우 어쩌면 필요가 없습니다 CI
그렇지 않으면, 당신은 CI가 필요합니다

업데이트
결과를 읽음으로써 잘못된 방향과 잘못된 이유로 CI에 접근했다고 결론을 내릴 수 있습니다.

팀으로도 노력할 가치가 있습니다. 크로스 플랫폼 코드를 개발할 때 변경 사항이 두 플랫폼에서 모두 작동하는지 확인해야 할 때 특히 그렇습니다. 예를 들어, Microsoft의 C ++ 컴파일러는 GCC보다 수용력이 뛰어나므로 Windows에서 개발하지만 Linux도 지원해야하는 경우 Linux에서 빌드가 중단되면 CI 시스템이 알려주는 것이 큰 도움이됩니다.

일부 CI 시스템은 설정하기가 쉽기 때문에 오버 헤드가 그리 크지 않습니다. 예를 들어 Jenkins 또는 Hudson을 사용해보십시오.

당신이 말했듯이 그것을 설정하고 계속 실행하는 데 드는 오버 헤드 비용이 있습니다.

그러나 브레이크 짝수 지점의 위치에 대한 문제는 팀에 몇 명의 사람들이 있는지가 아니라 프로젝트 기간의 기능입니다.

그러나 미래의 모든 프로젝트에서 사용할 수있는 설정 비용의 일부가 있으므로 장기적으로 오버 헤드 비용이 0에 가까워 질 수 있습니다.

이번 주에 Jenkins를 설정하여 작업중 인 작은 .NET 프로젝트를 빌드했습니다. 모든 커밋에서 빌드를 트리거하도록 Git 소스 컨트롤과 통합했습니다. 단위 테스트를 빌드에 통합했습니다. FxCop 및 StyleCop 위반 형태로 정적 분석을 통합했습니다.

이제 체크인 할 때마다 모든 코드를 체크 아웃하고 빌드하고 모든 어셈블리에서 버전 번호를 증가 시키며 테스트하고 FxCop 및 StyleCop 위반에 대해 분석하고 빌드를 보관하고 결과를 여러 그래프에 기록합니다. 테스트 결과 및 위반에 대한 가시성을 가지고 있습니다.

처음부터 다시 수행하는 데 1 시간 정도 걸립니다 (이전에 수행하지 않은 경우 Google에서 하루가 걸릴 수 있음). 모든 도구를 무료로 사용할 수 있기 때문에 비용이 들지 않습니다.

프로젝트를 빌드 할 때 비용이 들지 않으면 서 성장할 고품질 인프라가 있습니다. 새로운 개발자가 프로젝트에 참여하는 경우, 작업에 대한 가시성과 프로젝트에 대한 영향을 무료로 얻을 수 있습니다.

따라서 CI가 가치가 없다는 것을 알 수있는 유일한 시나리오는 하루 정도 걸리고 다시 방문하지 않는 프로젝트 또는 기존 / 무료 도구가없는 언어 및 구입 비용에 대한 시나리오입니다. 작업에 비례하지 않습니다.

각 변경 후 프로젝트의 모든 측면을 확인할 수 있으면 CI가 필요하지 않습니다.

다른 모든 경우에는 순 승리입니다.

오버 헤드가 최소화됩니다. 한 사람의 프로젝트에 유용하다고 말하고 싶습니다. 두 가지에 도달하면 매우 중요합니다.

"한 단계 빌드 / 확인"을 사용하는 한 사람의 프로젝트에 대해서는 지속적인 통합으로 괜찮을 수도 있지만 이러한 경우 CI를 설정하기 위해 대부분의 노력을 기울 였으므로 공식 시스템 (CC, Hudson, TeamCity 등)에서 사용합니다.

CI가 언제 스스로 비용을 지불하는지에 대한 문제는 새로운 프로젝트에 대한 답을 찾기가 어렵습니다.

기존 프로젝트에서는 훨씬 쉽게 볼 수 있습니다. 공급망의 개발 부분에서 중요한 버그를 발견하면 가능한 한 빨리 문제가 존재한다는 것을 알고 있습니다. 수정 비용이 이제 가장 낮습니다. 이 문제가 개발 위의 환경에 존재하면 비용이 더 높습니다.

이제 경영진은 버그로 릴리스하기로 결정할 수도 있지만 이는 비즈니스 위험입니다. 적어도 지금은 심야 전화 / 공황보다는 위험 평가를 통해 완화 될 수 있습니다. 시간당 요금으로 청구되는 경우 막대한 비용이 발생합니다.

비용 측면에서 고려해야 할 또 다른 사항. 품질 관리 부서는 어떤가요? 수동 테스트입니까? CI를 사용하면 개발 상자에 대해 해당 스크립트를 자동화하여 전체 QA 비용을 줄일 수 있습니다. CI 단계에 참여함으로써 프로젝트를 지원하는 QA 직원 수를 줄일 수 있습니다.

CI는 항상 항상 가치가 있습니다. 보안이 제공되므로 다른 방법보다 더 빠른 속도로 작업 할 수 있습니다. 당신이 가지고있는 문제는 단위 테스트와 관련이 있습니다. 나는 단위 테스트가 매우 비싸다는 것에 동의하지만, (많은 것들에 대해서는) 그것이 우리가 가진 가장 최악의 옵션이라고 생각합니다. 개인적으로, 그리고 내가 일하는 경향이있는 종류의 시스템에 대해, 나는 실제 및 (아마도 합성적인) 병리학 적 사례의 조합에서 작동하는 시스템 레벨 테스트를 맹세합니다. 단위 테스트보다 저렴하고 개념적 우주의 도달하기 어려운 코너 인 Donald Rumsfeld의 "Unknown Unknowns"에 도달합니다.

팀 규모에 관계없이 항상 사용하십시오. 예를 들어, 누가 당신인지 알고 있다면 스타 벅스의 랩톱에서 코딩하고 집에서 더 강력한 시스템을 계속 사용하고 있습니까?

오버 헤드는 그렇게 나쁘지 않습니다.

하나. 예, 지속적인 통합을 사용하기에 충분합니다.

얼마나 많은 개발자의 문제가 아니라

에이. 자동화를 사용하여 절약하는 시간과 빈도

• 통합 후 구축, 자동화 된 테스트 실행 및 설정 생성에 소요되는 시간 절약 * 체크인 빈도 = 절약 된 시간의 백분율.

비. 보유한 버전 / 분기 / 제품 수

• 두 명의 다른 지점에서 일하는 한 명의 개발자가있는 경우 각 지점마다 빌드, 테스트 및 패키징이 필요하므로 시간이 두 배로 늘어납니다.