저는 대규모 조직에서 일한 적이 없으며 "Build Server"가있는 회사에서 일한 적이 없습니다.
그들의 목적은 무엇입니까? 개발자가 로컬 컴퓨터에서 프로젝트를 빌드하지 않는 이유는 무엇입니까? 일부 프로젝트가 너무 커서 합리적인 시간에 빌드하려면 더 강력한 기계가 필요합니까?
빌드 서버가 유용하다고 생각하는 유일한 곳은 저장소에 커밋 된 내용을 지속적으로 빌드하는 빌드 서버와의 지속적인 통합입니다. 내가 충분히 큰 프로젝트에서 일하지 않았습니까?
누군가 저를 계몽하십시오 : 빌드 서버의 목적은 무엇입니까?
답변:
주어진 이유는 실제로 큰 이점입니다. QA로 이동하는 빌드는 리포지토리에서만 빌드하는 시스템에서만 가져와야합니다. 이렇게하면 빌드 패키지를 재현하고 추적 할 수 있습니다. 개발자가 자신의 테스트를 제외하고 수동으로 코드를 작성하는 것은 위험합니다. 물건이 체크인되지 않거나 다른 사람의 변경 사항으로 인해 구식이 될 위험이 너무 많습니다.
빌드 서버는 여러 가지 이유로 중요합니다.
그들은 환경을 격리합니다. 지역 코드 몽키 개발자 는 여러분의 컴퓨터에서 컴파일되지 않을 때 " 내 컴퓨터에서 컴파일됩니다"라고 말합니다 . 이는 동기화되지 않은 체크인을 의미하거나 종속 라이브러리가 누락되었음을 의미 할 수 있습니다. Jar 지옥은 .dll 지옥만큼 나쁘지 않습니다. 어느 쪽이든 빌드 서버를 사용하는 것은 빌드가 신비롭게 실패하거나 실수로 잘못된 라이브러리를 패키징하지 않도록하는 저렴한 보험입니다.
빌드와 관련된 작업에 중점을 둡니다. 여기에는 빌드 태그 업데이트, 배포 패키징 생성, 자동화 된 테스트 실행, 빌드 보고서 생성 및 배포가 포함됩니다. 자동화가 핵심입니다.
그들은 (분산) 개발을 조정합니다. 표준 사례는 여러 개발자가 동일한 코드 기반에서 작업하는 경우입니다. 버전 제어 시스템은 이러한 종류의 분산 개발의 핵심이지만 도구에 따라 개발자가 서로의 코드와 많이 상호 작용하지 않을 수 있습니다. 개발자가 잘못된 빌드를 위험에 빠뜨리거나 지나치게 공격적으로 코드 병합에 대해 걱정하도록하는 대신 자동화 된 빌드가 적절한 코드를보고 예측 가능한 방식으로 빌드 아티팩트를 처리 할 수있는 빌드 프로세스를 설계하십시오. 이렇게하면 개발자가 새 파일 종속성을 체크인하지 않는 등 문제가있는 무언가를 커밋 할 때 신속하게 알림을받을 수 있습니다. 단계적 영역에서이 작업을 수행하면 개발자가 로컬 빌드를 손상시키는 코드를 가져 오지 않도록 빌드 된 코드에 플래그를 지정할 수 있습니다. PVCS는 프로모션 그룹의 아이디어를 사용하여이를 잘 수행했습니다. Clearcase도 라벨을 사용하여이를 수행 할 수 있지만 많은 상점에서 제공하는 것보다 더 많은 프로세스 관리가 필요합니다.
그들의 목적은 무엇입니까?
개발자 컴퓨터의 부하를 받아 안정적이고 재현 가능한 빌드 환경을 제공합니다.
개발자가 로컬 컴퓨터에서 프로젝트를 빌드하지 않는 이유는 무엇입니까?
복잡한 소프트웨어의 경우 "컴파일"만하면 놀랍도록 많은 일이 잘못 될 수 있기 때문입니다. 실제로 발생한 문제 :
모든 공개 릴리스는 소스 제어에서 빈 폴더로 가져 오는 것으로 시작하므로 안정성이 크게 향상되었습니다. 전에는 "조가 새 DLL을 주었을 때 사라진" "재미있는 문제"가 많이있었습니다.
일부 프로젝트가 너무 커서 합리적인 시간에 빌드하려면 더 강력한 기계가 필요합니까?
"합리적"이란 무엇입니까? 로컬 머신에서 배치 빌드를 실행하면 할 수없는 일이 많이 있습니다. 개발자에게 빌드 완료 비용을 지불하는 대신 IT 비용을 지불하여 이미 실제 빌드 머신을 구입하십시오.
내가 충분히 큰 프로젝트에서 일하지 않았습니까?
크기는 확실히 하나의 요소이지만 유일한 요소는 아닙니다.
빌드 서버는 Continuous Integration 서버와 구별되는 개념입니다. CI 서버는 변경 사항이있을 때 프로젝트를 빌드하기 위해 존재합니다. 대조적으로 빌드 서버는 깨끗한 환경에서 프로젝트 (일반적으로 태그 된 개정에 대한 릴리스)를 빌드하기 위해 존재합니다. 개발자 해킹, 조정, 승인되지 않은 구성 / 아티팩트 버전 또는 커밋되지 않은 코드가 릴리스 된 코드에 포함되지 않도록합니다.
안정성, 추적 성 및 재현성에 대한 지금까지의 답변에 동의합니다. (많은 'ity', 맞죠?). 많은 빌드 서버를 사용하는 대기업 (의료, 금융)에서만 일한 적이 있었기 때문에 보안에 관한 것이기도합니다. 영화 사무실 공간을 본 적이 있습니까? 불만을 품은 개발자가 자신의 로컬 컴퓨터에 뱅킹 애플리케이션을 구축하고 아무도 그것을 보거나 테스트하지 않는다면 ... BOOM. 슈퍼맨 III.
이러한 기계는 여러 가지 이유로 사용되며 모두 우수한 제품을 제공하는 데 도움이됩니다.
한 가지 용도는 일반적인 최종 사용자 구성을 시뮬레이션하는 것입니다. 제품은 모든 개발 도구 및 라이브러리가 설정된 컴퓨터에서 작동 할 수 있지만 최종 사용자는 대부분 동일한 구성을 갖지 않을 것입니다. 그 문제에 대해 다른 개발자도 당신과 똑같은 설정을 갖지 못할 것입니다. 코드 어딘가에 하드 코딩 된 경로가있는 경우 컴퓨터에서 작동 할 수 있지만 Dev El O'per가 동일한 코드를 빌드하려고하면 작동하지 않습니다.
또한 누가 마지막으로 제품을 고장 냈는지, 어떤 업데이트를 통해 제품이 어디에서 퇴보했는지 모니터링하는 데 사용할 수 있습니다. 새 코드가 체크인 될 때마다 빌드 서버가이를 빌드하고 실패하면 무언가 잘못되었으며 마지막으로 커밋 한 사용자가 잘못되었음을 분명히 알 수 있습니다.
개발자가 자신의 컴퓨터에서 빌드 할 수 있다는 것이 맞습니다.
그러나 다음은 우리 빌드 서버가 우리에게 구매하는 것 중 일부이며, 우리는 거의 정교한 빌드 제작자가 아닙니다.
어쩌면 나만 ...
모두가 동의해야한다고 생각합니다
그러나 아무도 자동으로 빌드 된 버전에 관심이 없습니다. 자동 빌드에서 무언가가 깨졌지만 더 이상 그렇지 않은 경우-누가 신경 쓰나요? 진행중인 작업입니다. 누군가 고쳤습니다.
릴리스 버전을 수행하려면 저장소에서 빌드를 실행합니다. 그리고 서버가 작동 할 때 6 시간마다가 아니라 그 당시 저장소의 버전에 태그를 지정하고 싶을 것입니다.
따라서 "빌드 서버"는 잘못된 이름 일 뿐이며 실제로는 "지속적인 테스트 서버"입니다. 그렇지 않으면 거의 쓸모없는 것 같습니다.