BazelCon 2022는 11월 16~17일에 뉴욕과 온라인에서 개최됩니다.
지금 등록하기

빌드 시스템을 사용해야 하는 이유

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 페이지에서는 빌드 시스템이 무엇인지, 어떤 역할을 하는지, 빌드 시스템을 사용해야 하는 이유는 무엇인지, 그리고 조직 확장이 시작될 때 컴파일러와 빌드 스크립트가 가장 적합한 선택이 아닌 이유에 관해 설명합니다. 빌드 시스템에 대한 경험이 많지 않은 개발자를 대상으로 합니다.

빌드 시스템이란 무엇인가요?

기본적으로 모든 빌드 시스템은 엔지니어가 작성한 소스 코드를 머신에서 읽을 수 있는 실행 가능한 바이너리로 변환하는 간단한 용도로 사용됩니다. 빌드 시스템은 사람이 작성한 코드뿐만 아니라 또한 테스트용 또는 출시용 머신에 상관없이 머신이 빌드를 자동으로 만들 수 있게 해줍니다. 수천 명의 엔지니어가 참여하는 조직에서는 대부분의 빌드가 엔지니어에 의해 직접 트리거되는 대신 자동으로 트리거되는 경우가 많습니다.

컴파일러만 사용할 수 없나요?

빌드 시스템의 필요성이 즉시 드러나지 않을 수도 있습니다. 대부분의 엔지니어는 코딩을 배우는 동안 빌드 시스템을 사용하지 않습니다. 대부분 명령줄에서 직접 gcc 또는 javac와 같은 도구를 호출하거나 통합 시 코드를 호출하는 것부터 시작합니다. 합니다. 모든 소스 코드가 동일한 디렉터리에 있는 경우 다음과 같은 명령어가 작동합니다.

javac *.java

이는 자바 컴파일러가 현재 디렉터리의 모든 자바 소스 파일을 바이너리 클래스 파일로 변환하도록 지시합니다. 가장 간단한 경우에는 이 모든 작업이 필요합니다.

그러나 코드가 확장되는 즉시 정보 표시가 시작됩니다. javac는 현재 디렉터리의 하위 디렉터리를 찾아서 가져올 코드를 충분히 찾아냅니다. 하지만 파일 시스템의 다른 부분 (여러 프로젝트에서 공유하는 라이브러리)에 저장된 코드는 찾을 수 없습니다. 또한 자바 코드를 빌드하는 방법만 알고 있습니다. 대규모 시스템에는 다양한 프로그래밍 언어로 작성된 다양한 요소가 관련될 때가 많습니다. 즉, 이러한 요소 간 종속 항목이 있는 웹에서 단일 언어를 위한 컴파일러가 없기 때문에 전체 시스템을 빌드할 수 없습니다.

여러 언어 또는 여러 컴파일 단위의 코드를 처리하면 코드 작성이 더 이상 한 단계 프로세스가 아닙니다. 이제 코드에 종속된 항목을 평가하고 각 부분에 서로 다른 도구 모음을 사용하여 적절한 순서로 빌드해야 합니다. 종속 항목이 변경되면 이 프로세스를 반복하여 오래된 바이너리에 종속되지 않도록 해야 합니다. 코드가 균등한 코드베이스의 경우 이 프로세스는 빠르게 번거롭고 오류가 발생하기 쉽습니다.

또한 컴파일러는 자바의 타사 JAR 파일과 같은 외부 종속 항목을 처리하는 방법에 관해 전혀 알지 못합니다. 빌드 시스템이 없어도 인터넷에서 종속 항목을 다운로드하고 하드 드라이브의 lib 폴더에 고정한 후 컴파일러가 해당 디렉터리의 라이브러리를 읽도록 구성하여 이 문제를 관리할 수 있습니다. 에서 확인할 수 있습니다. 시간이 지남에 따라 이러한 외부 종속 항목의 업데이트, 버전, 소스를 유지하기가 어렵습니다.

셸 스크립트는 어떻게 되나요?

취미 프로젝트가 컴파일러만으로도 빌드할 수 있을 정도로 단순해졌지만 앞서 설명한 몇 가지 문제가 발생했다고 가정해 보겠습니다. 여전히 빌드 시스템이 필요하지 않다고 생각할 수 있으며, 올바른 순서로 빌드를 처리하는 간단한 셸 스크립트를 사용하여 지루한 부분을 자동화할 수 있습니다. 이 문제는 한동안 도움이 되지만, 곧 문제가 더 발생할 것입니다.

  • 지루해. 시스템이 더 복잡해짐에 따라 실제 스크립트에서 빌드 스크립트를 작업하는 데 거의 많은 시간을 보내기 시작합니다. 셸 스크립트 디버깅은 점점 더 많은 해킹이 중첩되어 고통스러워집니다.

  • 속도가 느립니다. 실수로 오래된 라이브러리에 의존하지 않도록 할 때마다 빌드 스크립트에서 모든 종속 항목을 순서대로 빌드하도록 하면 됩니다. 어떤 부분을 다시 빌드해야 하는지 감지하는 로직을 추가하려고 하지만 스크립트의 경우 상당히 복잡하고 오류가 발생하기 쉽습니다. 또는 매번 다시 빌드해야 하는 부분을 지정하는 방법도 생각해 보겠습니다. 그러면 정사각형으로 돌아갑니다.

  • 좋은 소식을 전해드립니다. jar 명령어에 전달하여 최종 빌드를 만드는 데 필요한 모든 인수를 파악하는 것이 좋습니다. 이를 업로드하고 중앙 저장소에 푸시하는 방법을 기억하세요. 문서 업데이트를 빌드하여 푸시하고 사용자에게 알림을 보낼 수 있습니다. 음, 다른 스크립트를 요청했을 수도 있습니다.

  • 재해! 하드 드라이브가 비정상 종료되므로 이제 전체 시스템을 다시 만들어야 합니다. 모든 소스 파일을 버전 제어에 유지할 수 있을 만큼 스마트하게 작동했지만 다운로드한 라이브러리를 사용하면 어떨까요? 다시 찾아볼 때 처음 다운로드할 때와 동일한 버전인지 확인할 수 있나요? 특정 위치에 설치된 특정 도구에 의존하는 스크립트일 수 있습니다. 스크립트가 다시 작동하도록 동일한 환경을 복원할 수 있나요? 컴파일러가 제대로 작동하도록 하기 위해 오래 전에 설정한 모든 환경 변수는 어떨까요?

  • 많은 문제에도 불구하고 프로젝트는 더 성공적이므로 더 많은 엔지니어를 고용할 수 있습니다. 이제 이전 문제가 발생하지 않도록 재해가 발생하지 않는다는 것을 알게 되었습니다. 새로운 개발자가 팀에 합류할 때마다 동일한 어려운 부트스트랩 프로세스를 거쳐야 합니다. 최선의 노력에도 불구하고 각 개인의 시스템에는 여전히 작은 차이점이 있습니다. 한 사람의 머신에서 작동하는 기능이 다른 시스템에서는 작동하지 않는 경우가 많으며, 이러한 차이가 있는지 알아내기 위해서는 몇 시간 동안 디버깅 도구 경로나 라이브러리 버전을 사용할 때마다 필요합니다.

  • 빌드 시스템을 자동화해야 한다고 결정합니다. 이론적으로는 새 컴퓨터를 가져와서 크론을 사용하여 매일 밤 빌드 스크립트를 실행하도록 설정하는 것만큼 간단합니다. 여전히 어려운 설정 프로세스를 거쳐야 하지만 지금은 인간의 뇌가 사소한 문제를 감지하고 해결할 수 있는 이점이 없습니다. 이제 어제는 개발자가 아침에 작업했지만 자동 빌드 시스템에서는 작동하지 않는 변경사항을 실행했기 때문에 매일 아침 아침에 빌드가 실패했음을 알 수 있습니다. 수정은 간단하지만 항상 그렇기 때문에 매일 이렇게 간단한 수정 사항을 발견하고 적용하는 데 많은 시간이 걸립니다.

  • 프로젝트 규모가 커질수록 빌드 속도가 느려집니다. 하루는 빌드가 완료될 때까지 기다리는 동안 휴가 중인 동료의 유휴 데스크톱을 보며 컴퓨팅 낭비를 모두 활용할 수 있기를 바랐습니다. 전원

전통적인 규모의 확장 문제에 직면했습니다. 한 주에서 최대 1~2주 동안 코드 수백 줄로 작업하는 단일 개발자의 경우 (이제 막 졸업한 신입생 개발자만이 지금까지의 경험이 많을 수 있음) 컴파일러만 있으면 됩니다. 스크립트를 사용하면 조금 더 복잡해질 수 있습니다. 하지만 여러 개발자와 머신 간에 조율해야 하는 상황이라면 완벽한 빌드 스크립트만으로는 충분하지 않습니다. 이러한 머신의 사소한 차이를 설명하기가 매우 어렵기 때문입니다. 이제 이 간단한 접근 방식은 세분화되어 있으며 실제 빌드 시스템에 투자할 때입니다.