빌드 스크립트의 장점은 무엇입니까?

필자의 프로그래밍 경력 중 대부분은 실행 가능한 프로그램을 생성하기 위해 작업중인 IDE에서 "build / compile / run"명령을 사용했습니다. 이것은 하나의 버튼으로 매우 쉽습니다. 다른 언어와 프레임 워크에 대해 더 많이 배우면서 프로젝트 실행을위한 "빌드 스크립트"(ANT, Maven, Gradle 등)에 대한 이야기가 점점 더 많이 나옵니다. 이것에 대한 나의 이해는 구성 세부 사항을 지정하는 컴파일러 / 링커 / 마술 프로그램 제작자에게 지시 사항이라는 것입니다.

학교에서 makefile을 다시 작성하는 것을 기억하지만 특별한 이점은 없었습니다 (유닉스 터미널에서 쓸 때만 사용했습니다. 편리한 "빌드"버튼이있는 IDE는 없었습니다). 그 외에도, 여기에서 빌드 스크립트가 단순히 프로그램을 만드는 것 이상의 기능을 수행하는 방법에 대해 논의하는 다른 질문을 보았습니다 . 호스트 시스템에 관계없이 단위 테스트 를 수행 하고 리소스 를 보호 할 수 있습니다 .

개발자로서 이해하기 위해 빌드 스크립트가 중요하다는 느낌을 떨칠 수는 없지만 의미있는 설명을 원합니다. 빌드 스크립트를 사용해야하는 이유는 무엇입니까?

빌드 스크립트 및 빌드 서버의 책임은 더 넓은 범위 내에서의 역할에 대해 설명합니다. 빌드 스크립트에서 제공하는 특정 장점과 IDE의 "빌드 / 실행"명령 또는 이와 유사한 간단한 방법을 찾고 있습니다.

오토메이션.

개발할 때 가장 단순한 프로젝트에서만 기본 "빌드"버튼으로 필요한 모든 작업을 수행 할 수 있습니다. API에서 WS를 작성하고, 문서를 생성하고, 외부 자원과 링크하고, 변경 사항을 서버에 배치하는 등의 작업이 필요할 수 있습니다. 일부 IDE에서는 추가 단계 또는 빌더를 추가하여 빌드 프로세스를 사용자 정의 할 수 있지만 이는 사용자가 IDE 상품을 통해 빌드 스크립트 생성

그러나 시스템 개발은 코드를 작성하는 것만이 아닙니다. 여러 단계가 관련되어 있습니다. IDE 독립 스크립트는 자동으로 실행될 수 있으며 이는 다음을 의미합니다.

• 버전 제어 변경을 커밋하면 서버에서 새 빌드를 자동으로 시작할 수 있습니다. 빌드에 필요한 것을 커밋하지 않았는지 확인합니다.

• 마찬가지로 빌드가 완료된 후 테스트를 자동으로 실행하여 문제가 발생했는지 확인할 수 있습니다.

• 이제 나머지 조직 (QA, sysadmins)은

  a) 컨트롤 버전에서만 완벽하게 재현 할 수 있습니다.

  b) 그들 모두에게 공통적이다.

내가 일인 팀으로 일할 때도 그 목적을 위해 대본을 사용했습니다. 수정 프로그램을 개발했을 때 SVN에 커밋하고 SVN을 다른 디렉토리로 다시 내보내고 빌드 스크립트를 사용하여 솔루션을 생성 한 다음 프리 프로덕션 시스템으로, 나중에 프로덕션으로 이동합니다. 몇 주 후에 (내 로컬 코드베이스가 이미 변경된 상태에서) 누군가 버그에 대해 불평했다면, 시스템을 올바르게 디버깅하기 위해 어떤 SVN 개정판을 체크 아웃해야하는지 정확히 알 것입니다.

코드와 마찬가지로 빌드 스크립트는 컴퓨터에서 실행됩니다. 컴퓨터는 일련의 지침을 따르는 데 매우 능숙 합니다. 실제로, (자체 수정 코드가 아닌) 컴퓨터는 동일한 입력이 주어지면 동일한 순서의 명령을 정확히 동일한 방식으로 실행합니다. 이것은 컴퓨터 만 일치 할 수있는 수준의 일관성을 제공합니다.

대조적으로, 우리의 물로 채워진 살백은 다음 단계에서 똑바로 비열합니다. 그 성가신 분석 뇌는 모든 것을 만나는 것에 의문을 갖는 경향이 있습니다. "아 ... 그럴 필요가 없습니다"또는 "정말이 플래그를 사용해야합니까? 어 ... 그냥 무시하겠습니다." 또한, 우리는 만족하는 경향이 있습니다. 우리가 몇 번 무언가를 한 후에, 우리는 우리가 지시 사항을 알고 있다고 믿고 믿기 시작하고 지시 시트를 볼 필요가 없습니다.

"실용적인 프로그래머"에서 :

또한 프로젝트에서 일관성과 반복성을 보장하려고합니다. 수동 절차는 일관성을 변화시킵니다. 특히 절차의 측면이 다른 사람들에 의해 해석 될 수있는 경우 반복성이 보장되지 않습니다.

또한 컴퓨터와 비교하여 명령 실행이 매우 느립니다. 수백 개의 파일과 구성이 포함 된 대규모 프로젝트에서는 빌드 프로세스의 모든 단계를 수동으로 실행하는 데 몇 년이 걸립니다.

나는 당신에게 실제적인 예를 줄 것입니다. 나는 대부분의 코드가 몇 가지 다른 하드웨어 플랫폼에서 공유되는 임베디드 소프트웨어를 사용하고있었습니다. 플랫폼마다 하드웨어가 다르지만 대부분의 소프트웨어는 동일했습니다. 그러나 각 하드웨어마다 다른 부분이 거의 없었습니다. 이상적으로, 공통 부분은 라이브러리에 배치되고 각 버전에 링크됩니다. 그러나 공통 부분을 공유 라이브러리로 컴파일 할 수 없습니다. 모든 구성마다 컴파일해야했습니다.

처음에는 각 구성을 수동으로 컴파일했습니다. 구성간에 전환하는 데 몇 초 밖에 걸리지 않았으며 그렇게 큰 어려움은 없었습니다. 프로젝트가 끝날 무렵, 코드의 공유 부분에서 심각한 결함이 발견되어 장치가 본질적으로 통신 버스를 인계 받게됩니다. 이것은 나빴다! 정말 나빠 코드에서 버그를 찾아 수정하고 모든 버전을 다시 컴파일했습니다. 하나만 빼고 빌드 과정에서 혼란스러워서 잊어 버렸습니다. 이진 파일이 릴리스되고 컴퓨터가 구축되었으며 하루 후 컴퓨터가 응답하지 않는다는 전화를 받았습니다. 나는 그것을 확인하고 장치가 버스를 잠근 것을 발견했다. "그러나 나는 그 버그를 고쳤다!".

나는 그것을 고쳤을지도 모르지만, 그 한 보드에 길을 찾지 못했습니다. 왜? 한 번의 클릭으로 모든 단일 버전을 빌드하는 자동화 된 빌드 프로세스가 없었기 때문입니다.

당신이하고 싶은 모든 것이 <compiler> **/*.<extension>이면, 빌드 스크립트는 거의 목적을 제공하지 않습니다 ( Makefile프로젝트에서 a를 볼 경우으로 빌드 할 수 있다고 알고 있습니다 make). 사소한 프로젝트는 대개 그 이상을 필요로합니다. 최소한 라이브러리를 추가하고 (프로젝트가 성숙함에 따라) 빌드 매개 변수를 구성해야합니다.

IDE는 일반적으로 최소한 구성 가능하지만 이제 빌드 프로세스는 IDE 특정 옵션에 의존합니다. Eclipse 를 사용하는 경우 Alice는 NetBeans를 선호 하고 Bob은 IntelliJ IDEA 를 사용하려는 경우 구성을 공유 할 수 없으며 사용자 중 하나가 소스 제어에 변경 사항을 푸시 할 때 IDE에서 작성된 구성을 수동으로 편집해야합니다. 다른 개발자의 파일을 보거나 다른 개발자에게 직접 알리도록하십시오 (즉, 일부 IDE에 대해 IDE 구성이 잘못된 위치에 커밋이 있음을 의미합니다 ...).

또한 팀에서 사용하는 각 IDE마다 변경을 수행하는 방법을 알아 내야하며, 그 중 하나가 특정 설정을 지원하지 않는 경우 ...

이제이 문제는 문화에 따라 다릅니다. 개발자가 IDE를 선택하지 않아도 될 수도 있습니다. 그러나 IDE 사용 경험이있는 개발자는 일반적으로 IDE를 사용할 때 더 행복하고 효율적이며, 텍스트 편집기 사용자는 자신이 좋아하는 도구에 대해 종교적으로 열광하는 경향이 있으므로 개발자에게 자유를주고 싶은 곳 중 하나입니다. 그리고 빌드 시스템을 사용하면 그렇게 할 수 있습니다. 어떤 사람들은 빌드 시스템 환경 설정을 가지고 있지만 IDE / 편집기 환경 설정만큼 광신하지는 않습니다 ...

모든 개발자가 동일한 IDE를 사용하도록하더라도 빌드 서버가 그것을 사용하도록 설득하는 것이 행운입니다 ...

이제는 간단한 빌드 프로세스 사용자 정의를위한 것이며 IDE는 멋진 GUI를 제공하는 경향이 있습니다. 컴파일 전 사전 처리 / 자동 생성 소스 파일과 같이보다 복잡한 작업을 원한다면 일반적으로 IDE 구성 내의 일부 기본 텍스트 영역에 사전 빌드 스크립트를 작성해야합니다. 어떤 부분을 코딩해야하는 빌드 시스템이지만 코드를 작성하는 실제 편집기에서 수행 할 수 있으며, 더 중요한 것은 빌드 시스템의 프레임 워크 자체가 일반적으로 이러한 스크립트를 구성하는 데 약간의 지원을 제공한다는 것입니다.

마지막으로, 빌드 시스템은 프로젝트를 구축하는 것 이상으로 유용합니다. 팀의 모든 사람이 수행해야하는 다른 작업을 수행하도록 시스템을 프로그래밍 할 수 있습니다. 에서 루비 온 레일즈 , 예를 들어, 등, 임시 파일을 청소 빌드 시스템에서 이러한 작업을 가하고 있습니다, 데이터베이스 마이그레이션을 실행하기위한 시스템 작업을 구축가 팀에있는 모든 사람이 일관되게 할 수 있도록합니다.

많은 IDE는 단순히 무언가를 빌드하는 데 사용되는 명령을 패키지 한 다음 스크립트를 생성하고 호출합니다!

예를 들어 Visual Studio의 경우 '명령 줄'상자에서 C ++ 컴파일에 대한 명령 줄 매개 변수를 볼 수 있습니다. 빌드 출력을 자세히 보면 컴파일을 실행하는 데 사용 된 빌드 스크립트가 포함 된 임시 파일이 표시됩니다.

요즘은 모두 MSBuild 이지만 여전히 IDE에서 직접 실행됩니다.

따라서 명령 행을 사용하는 이유는 소스로 바로 가서 중개자, 즉 업데이트되지 않았거나 헤드리스 서버에서 원하지 않거나 필요하지 않은 종속성을 필요로하는 중개자를 건너 뛰기 때문입니다. CI ( Continuous Integration ) 서버 역할을 합니다.

또한 스크립트는 일반적인 개발자 중심 단계보다 더 많은 작업을 수행합니다. 예를 들어, 빌드 후에 바이너리를 패키지화하여 특별한 위치에 복사하거나 설치 프로그램 패키지를 작성하거나 문서 도구를 실행할 수 있습니다. 많은 다른 작업이 개발자 컴퓨터에서 무의미한 CI 서버에 의해 수행되므로 이러한 모든 단계를 수행하는 IDE 프로젝트를 만들 수 있지만 개발자를위한 프로젝트와 빌드를위한 프로젝트 중 두 가지를 유지해야합니다. 일부 빌드 작업 (예 : 정적 분석)은 개발자 프로젝트에 원하지 않는 시간이 오래 걸릴 수 있습니다.

간단히 말해서, 더 쉽습니다. 원하는 모든 작업을 수행 할 수있는 스크립트를 만들고 명령 줄이나 빌드 서버 구성에서 빠르고 간단하게 시작할 수 있습니다.

make

기억하고 타이핑하는 것보다 훨씬 쉽다

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

그리고 프로젝트는 매우 복잡한 컴파일 명령을 가질 수 있습니다. 빌드 스크립트에는 변경된 사항 만 다시 컴파일하는 기능이 있습니다. 깨끗한 빌드를하고 싶다면

make clean

중간 파일이 생성되었을 수있는 각각의 모든 장소를 기억하려고 시도하는 것보다 올바르게 설정 한 후 쉽고 안정적입니다.

물론 IDE를 사용하는 경우 빌드 또는 정리 버튼을 클릭하기도 쉽습니다. 그러나 커서를 화면의 특정 위치로 자동화하는 것은 훨씬 어렵습니다. 특히 창을 이동하면 간단한 텍스트 명령을 자동화하는 것보다 해당 장소가 이동할 수있는 경우가 더욱 그렇습니다.

다른 방법은 무엇입니까? 유일한 다른 방법은 하나의 긴 명령 행 명령을 지정하는 것입니다.

또 다른 이유는 makefile이 증분 컴파일을 허용하므로 컴파일 시간이 크게 단축됩니다.

Makefile은 또한 빌드 프로세스를 크로스 플랫폼으로 만들 수 있습니다. CMake는 플랫폼에 따라 다른 빌드 스크립트를 생성합니다.

편집하다:

IDE를 사용하면 특정 방식으로 작업 할 수 있습니다. 많은 사람들이 IDE와 같은 기능이 많지 않더라도 vim 또는 emacs를 사용합니다. 그들은이 편집자들이 제공하는 힘을 원하기 때문에 그렇게합니다. IDE를 사용하지 않는 사용자에게는 빌드 스크립트가 필요합니다.

IDE를 사용하는 사람들에게조차도 무슨 일이 일어나고 있는지 알고 싶을 수도 있으므로 빌드 스크립트는 GUI 접근 방식에는없는 구현에 대한 세부 정보를 제공합니다.

IDE 자체는 종종 내부적으로 스크립트를 빌드하기도합니다. 실행 버튼은 make 명령을 실행하는 또 다른 방법입니다.

위의 답변은 많은 좋은 근거를 다루지 만, 내가 추가하고 싶은 실제 사례 (카르마가 없기 때문에 주석으로 추가 할 수 없음)는 Android 프로그래밍입니다.

저는 전문적인 Android / iOS / Windows Phone 개발자이며 Google 서비스 API (대부분 Google Maps)를 많이 사용 합니다.

Android에서 이러한 서비스를 사용하려면 키 스토어 또는 개발자 ID 파일 형식을 개발자 콘솔에 내가 말한 사람임을 Google에 알려 주어야합니다. 내 앱이 다른 키 저장소로 컴파일 된 경우 앱의 Google지도 섹션이 작동하지 않습니다.

어쨌든 앱을 업데이트하는 데 실제로 사용할 수있는 12 개의 키 저장소를 개발자 콘솔에 추가하고 관리하는 대신이 저장소를 보안 저장소에 포함하고 Gradle을 사용하여 Android Studio에 빌드 할 때 사용할 키 저장소를 정확히 알려줍니다 "디버그"또는 "릴리스". 이제 Google 개발자 콘솔에 두 개의 키 저장소 만 추가하면됩니다 (하나는 "디버그"및 하나는 "릴리스"). 모든 팀원은 저장소를 복제하지 않고 개발자에게 갈 필요없이 바로 개발할 수 있습니다. 콘솔과, 더 자신의 특정 키 스토어의 SHA 해시를 추가하거나, 내가 그들을 관리하기. 이것은 각 팀 구성원에게 서명 키 저장소의 사본을 제공하는 추가 이점을 제공합니다. 즉, 내가 부재 중이고 업데이트가 예정된 경우 팀 구성원은 매우 짧은 지침 목록 만 따라야합니다. 최신 정보.

이와 같은 빌드 자동화는 빌드를 일관되게 유지하고 새로운 개발자, 새로운 머신을 얻거나 머신의 이미지를 다시 만들어야 할 때 설정 시간을 줄여 기술 부채를 줄입니다.

스크립트 장점 구축 :

• 변경 사항은 대화 상자의 다른 검사 옵션과 달리 코드처럼 보입니다 (예 : git diff 명령에서)

• 간단한 빌드보다 더 많은 결과물 만들기

이전 프로젝트 중 일부에서 빌드 스크립트를 사용하여 다음을 수행했습니다.

• 프로젝트 문서 생성 (산소 기반)
• 짓다
• 단위 테스트 실행
• 단위 테스트 범위 보고서 생성
• 바이너리를 릴리스 아카이브로 압축
• 내부 릴리스 노트 생성 ( "git log"메시지 기반)
• 자동 테스트

종종 자동화 된 방식으로 "빌드"버튼을 호출 할 수 있습니다 (예 : Visual Studio는 명령 줄 인수를 허용 함). 사람들은 빌드 버튼으로 제공 할 수없는 것을 필요로하는 즉시 빌드 스크립트를 작성합니다.

예를 들어, 대부분의 IDE에서는 한 번에 하나의 플랫폼 만 구축 할 수 있습니다. 또는 한 번에 하나의 언어 만 가능 합니다. 그런 다음 빌드 된 출력으로 수행하는 작업이 있습니다. IDE에서 출력을 모두 설치 패키지로 롤업 할 수 있습니까?