전용 빌드 머신의 목적은 무엇입니까?

여러 가지 상황으로 인해 마지막 빌드주기가 제대로 구축되지 않았기 때문에 사무실에서 전용 빌드 머신을 사용하여 향후 모든 배포를 수행하도록 캠페인을 수행했으며 상사는이 제안을 수락했습니다.

그러나 사무실에서 실제 기계를 사용하는 대신 여러 다른 그룹과 단일 기계를 공유해야합니다. 필요한 모든 정보를 사무실에두고 계단을 따라 걸어야하는 번거 로움이 있습니다. 간단한 빌드를 수행하기 위해 다른 사무실에 내가 왜 이것을 처음 제안했는지 궁금해합니다.

별도의 빌드 머신을 사용한다는 아이디어는 원래 로컬로 작성된 코드를 다른 개발자의 코드와 분리하고 머신에서 하이재킹 된 파일을 배포에서 분리하는 것이 었습니다. 또한 ClearCase 파일 관리 시스템과 관련하여 점점 커지고있는 문제를 해결하는 것이 었습니다.이 기능은 '종속성이있는'다른 활동도 포함하지 않는 한 특정 빌드 활동을 배포하지 않는 경우가 많습니다.

실제로이 프로세스를 진행하고 있으므로 빌드 머신 사용의 전체 목적을 잘못 이해했는지 궁금합니다. 테스트, 스테이징 및 프로덕션 환경에 대한 코드 배포에만이 머신을 사용하고 있기 때문에 개인 개발자 테스트 배포에는 해당되지 않으며, 어떤 목적으로도 사용되는지 확실하지 않습니다.

그렇다면 빌드 머신을 사용하는 실제 이유는 무엇이며, 올바르게 사용하는 것에 가깝습니까?

일반적으로 전용 빌드 머신뿐만 아니라 해당 전용 머신에서 빌드 서버를 실행합니다. 전용 빌드 머신은 개발자의 작업을 절대 차단하지 않고 중앙 머신에서 배포하는 이점을 제공합니다.

빌드 서버는 훨씬 더 많은 것을 제공합니다. 빌드 서버는 CI (연속 통합)를 허용합니다. 즉, VCS (git와 같은)로 푸시 할 때마다 자동으로 빌드되며 단위 테스트가 있으면 "원 클릭 배포"를 허용 할 수 있습니다. 빌드 또는 테스트가 실패하면 빌드 서버가 메일별로 통지 할 수 있습니다. 그들은 무슨 일이 있었는지에 대한 역사적인 데이터와 트렌드를 제공합니다.

빌드 서버는 일반적으로 브라우저에서 실행되는 웹 GUI를 사용하여 여러 사용자 또는 팀이 한 번에 액세스 할 수 있습니다.

Java 세계에서 가장 많이 사용되는 빌드 서버 중 하나는 Jenkins입니다. Jenkins는 C ++ 빌드에서도 완벽하게 작동합니다 (두 언어를 사용하는 것 같습니다). Jenkins는 프로그래밍 및 구축과 관련이없는 모든 종류의 작업을 실행할 수 있으므로 자동화 서버라고합니다.

Traubenfuchs의 답변 외에도 귀하의 질문에 빌드 머신이 필요한 또 다른 이유를 암시했습니다.

소프트웨어를 기반으로해서 당신의 컴퓨터, 그것은 다른 사람의 구축되는 것은 아닙니다. 컴퓨터에있는 임의의 임의 파일에 의존하고있을 수 있습니다 (버전 관리가 불가능할 수도 있음). 모호한 빌드 스크립트에서 호출 된 잊어 버린 일부 응용 프로그램 또는 라이브러리에 의존하고있을 수 있습니다.

전용 빌드 머신이있는 경우 설치된 빌드 머신을 알아야합니다. 이것은 잘 문서화되어야합니다. 몇 년 후 소프트웨어를 다시 빌드해야하는 경우 문서화 된 문서가 설치된 새 빌드 머신 만 작성하면됩니다.

전용 빌드 머신을 사용하는 주된 이유는 빌드를 수행하는 사람에 관계없이 일관된 빌드를 얻는 것입니다. 개발자 워크 스테이션은 거의 동일하지 않습니다. 각 빌드가 동일한 버전의 종속성 및 컴파일러 등을 사용하고 있음을 알기는 어렵습니다. 개발자 워크 스테이션 빌드의 최악의 문제 중 하나는 개발자가 버전 제어에 체크인되지 않은 코드에서 빌드 할 수 있다는 것입니다.

어떤 플랫폼 / 언어를 사용하고 있는지는 확실하지 않지만 소스 제어에서 직접 가져 오는 빌드 서버가 이상적입니다. 즉, 빌드가 필요한 경우 지정된 버전의 저장소에서 소스를 검색하여 자동으로 컴파일합니다. 이를 위해서는 자동화 된 빌드 도구를 사용하여 빌드를 스크립팅해야합니다. 이것이 없으면 1 단계가되어야합니다.

개발을 위해 로컬로 구축하는 데 아무런 문제가 없습니다. 로컬 테스트 단위 테스트, 코드 품질 분석 및 호닝 빌드 스크립트 작업을 수행해야합니다. 그렇지 않으면 많은 시간을 낭비하게됩니다. 빌드 서버의 출력은 잠재적으로 프로덕션으로 이동하려는 모든 것을위한 것입니다. 통합 및 승인 테스트와 같은 모든 QA 활동은 빌드 서버의 빌드에서만 수행해야합니다.

다른 답변에 따르면 빌드를 자동화해야하므로 다른 사무실로 갈 필요가 없습니다. 그러나 빌드 프로세스를 개선하기 위해 수행 할 수있는 특정 단계를 제안하겠습니다.

• 먼저, 빌드 서버에 대한 원격 액세스를 설정하십시오! "make"명령을 입력하여 수동으로 빌드하는 경우 "make"를 입력하기 위해 더 이상 다른 사무실로 걸어 갈 필요가 없습니다. 빌드 서버에 SSH를 연결하고 "make"를 입력하면됩니다. make 또는 이와 유사한 빌드 시스템을 아직 사용하지 않으면 그러한 빌드 시스템을 사용하십시오.
• 둘째, 버전 제어 시스템에서 최신 변경 사항을 자동으로 가져 와서 추가 단계가 될 수있는 지속적인 통합 환경을 설치하여 추가 단계로 만듭니다. Jenkins를 추천합니다. 단위 테스트 및 시스템 레벨 통합 테스트도 실행하도록 Jenkins를 설정하십시오 (그렇지 않은 경우 단위 테스트에서 시작하여 시스템 레벨 통합 테스트로 종료).
• 셋째, 다른 컴퓨터와 동일한 컴퓨터를 공유하는 데 문제가있는 경우 (예 : 어떤 운영 체제와 어떤 버전 및 비트 리티를 사용해야하는지에 대한 의견이 다른 경우) 가상화 사용을 고려하십시오. 오늘날 좋은 서버는 수많은 가상 머신을 실행할 수 있습니다. 아마도 두 아키텍처 모두에서 빌드가 작동한다는 것을 알 수 있도록 32 비트 시스템과 64 비트 시스템을 직접 설정할 수 있습니다.
• 마지막으로, 필요하지 않을 수 있습니다. 응용 프로그램 성능이 매우 중요하고 동시에 실행중인 다른 빌드 / 테스트 실행이 결과에 너무 많은 영향을 미치는 경우와 같이 전용 컴퓨터가 있어야하는 경우 전용 하드웨어 서버를 설치하십시오. 당신 만이 사용합니다. 그러나 가상 CPU 코어가 40 개 이상인 최신 서버에서는 동일한 CPU 코어에 대한 액세스를 공유하지 않는 몇 개의 가상 머신을 만드는 것이 비교적 간단합니다.

수동 빌드보다 공유 시스템을 훨씬 더 잘 고려할 것입니다. 현재 프로젝트에서 가상 머신을 사용하고 있지만 시스템 수준의 통합 성능 테스트가 필요하기 때문에 성능 테스트에 17 개의 가상 CPU 코어가 40 개있는 전용 서버로 이동하고 있습니다.

... 사무실에서 실제 기계를 사용하는 대신 단일 기계를 다른 여러 그룹과 공유해야합니다 ...

당신은 그것이 나쁜 것 같다고 말합니다.

이제 모든 빌드 (사용자 및 다른 팀)가 빌드하는 공통 빌드 서버가 있습니다. 빌드 일관성? 검사.

... 필요한 정보를 모두 가지고 사무실을 떠나 계단을 따라 다른 사무실로 걸어 가야하는 번거 로움은 왜 내가 처음으로 이것을 제안했는지 궁금해합니다.

여전히 수동으로 빌드를 수행하고 있지만 좋지 않습니다.

사용자 대신 빌드 요청을 제출 / 대기하고 해당 프로세스가 결과를 다시 보내도록하는 서버 프로세스가 필요합니다.

다른 관련 답변 외에도 문제의 시스템에서 빌드를 직접 실행하는 것처럼 들립니다.

안정적인 빌드 시스템의 경우, 특히 다른 사용자와 빌드 머신을 공유 할 때 가상 머신 내에서 빌드를 실행하는 것이 일반적입니다. 이렇게하면 코드가 의존하는 자체 버전의 응용 프로그램 또는 라이브러리를 설치하여 다른 사용자가 빌드 동작을 변경할 수 없습니다. 이것의 가장 큰 장점은 VM을 쉽게 백업 할 수 있으며 다른 PC (자체 개발 시스템 포함)에 쉽게 복제 할 수 있다는 것입니다.

개별 개발자의 IDE, OS, 라이브러리 구성에 관계없이 빌드를 수행 할 수있는 중앙 집중식 중립 위치를 제공합니다.

전용 빌드 머신을 사용하면 리포지토리에 코드를 푸시 할 때마다 다시 빌드 할 수 있습니다. 누군가 빌드를 중단하면 프로세스가 즉시 경고를 보내서 문제를 즉시 해결할 수 있습니다.

모든 것을 더 반복 가능하고 안정적으로 만들고 리포지토리에 종속성 문제가있는 깨진 쓰레기로 가득 차지 않도록하는 것 외에도 컴퓨터에서 빌드 작업을 수행하기 위해해야 ​​할 일이 무엇이든 복사하기 때문에 개발자의 삶이 더 쉬워집니다. 빌드 머신에서 수행되고 있습니다.