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

자동화.

개발 중일 때만 가장 간단한 프로젝트에서는 기본 “build”버튼이 필요한 모든 작업을 수행합니다. API에서 WS를 생성하고, 문서를 생성하고, 외부 리소스와 연결하고, 변경 사항을 서버에 배포하는 등의 작업이 필요할 수 있습니다. 일부 IDE를 사용하면 추가 단계 또는 빌더를 추가하여 빌드 프로세스를 사용자 지정할 수 있습니다. IDE 상품을 통해 빌드 스크립트를 생성합니다.

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

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

• 마찬가지로, 빌드가 완료된 후 테스트가 자동으로 실행되어 문제가 있는지 확인할 수 있습니다.

• 이제 나머지 조직 (QA, 시스템 관리자)은 제어 버전에서 완벽하게 재현 가능한

  a) 제품을 구축했습니다.

p>

b)는 그들 모두에게 공통적입니다.

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

댓글

• 이것이 IMHO의 베스트 답변입니다. 모두가 자신의 아이디어에 맞지만 이것은 실제로 빌드 스크립트를 원하는 이유를 보여줍니다. 프로젝트가 확장됨에 따라 앞으로 진행되는 자동화를 지원하기 때문에 많은 시간을 절약 할 수 있습니다.
• @Alexus 시간뿐만 아니라 멍청한 실수도 있습니다. 😉 ” 반복하면 지루함이 생깁니다. 지루함은 끔찍한 실수로 이어집니다. 끔찍한 실수는 ‘ 아직도 지루했으면 좋겠습니다.’ ” (멍청한 실수도 제때 측정 할 수 있지만 ‘ 여러 가지 원인으로 인해 ‘ 시간을 절약 할 수 있다는 사실을 인식하는 것이 중요합니다.)
• 1 인 프로젝트의 경우에도

  별도의 디렉토리에 빌드 “가 도움이 될 수 있습니다. 저는 ‘ Windows에서 크로스 컴파일도 확인해야하는 작업을하고 있으므로 Jenkins가 테스트를 빌드하고 실행 한 다음 크로스 컴파일 된 버전을 빌드하면 훨씬 더 자신감이 생깁니다 ( 물론 효율적입니다!) 버그 수정을 릴리스해야 할 때입니다.

• 재현 가능한 빌드에 대한 주장에 동의하지 않습니다. ‘ 오늘날 빌드 시스템에는 제어되지 않는 변수가 너무 많아 재현 가능한 빌드를 얻기가 매우 어렵습니다. 귀하의 주장은 완전히 사실이 아닌 즉시 사용할 수있는 것처럼 들립니다.
• @JonasGr ö ger Automation은 가장 큰 변수 : 인간.

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

반대로, 우리의 물로 채워진 살 주머니는 다음 단계와 관련하여 완전히 비열합니다. 그 성가신 분석적 두뇌는 그것이 발생하는 모든 것에 의문을 제기하는 경향이 있습니다. “아 … 그럴 필요 없어”또는 “정말이 플래그를 사용해야합니까? 어 .. 그냥 무시하겠습니다. 또한 우리는 안주하는 경향이 있습니다. 무언가를 몇 번 수행하면 지침을 알고 있다고 믿기 시작하고 지침 시트를 볼 필요가 없습니다.

From “The Pragmatic Programmer”:

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

또한 지침 실행이 매우 느립니다 ( 수백 개의 파일과 구성이있는 대규모 프로젝트에서는 빌드 프로세스의 모든 단계를 수동으로 실행하는 데 몇 년이 걸립니다.

실제 예를 들어 보겠습니다. 나는 일부 임베디드 소프트웨어를 작업하고 있었는데 대부분의 코드가 몇 가지 다른 하드웨어 플랫폼에서 공유되었습니다. 각 플랫폼에는 하드웨어가 다르지만 대부분의 소프트웨어는 동일했습니다. 그러나 각 하드웨어에 특정한 부분이 거의 없었습니다. 이상적으로는 공통 부분이 라이브러리에 배치되고 각 버전에 링크됩니다. 그러나 공통 부분은 공유 라이브러리로 컴파일 할 수 없습니다. 모든 다른 구성으로 컴파일해야했습니다.

처음에는 각 구성을 수동으로 컴파일했습니다. 전환하는 데 몇 초 밖에 걸리지 않았습니다. 구성, 그리고 그다지 큰 고통은 아니 었습니다. 프로젝트가 끝날 무렵, 코드의 공유 부분에서 중요한 결함이 발견되었습니다. 여기서 장치는 본질적으로 통신 버스를 대신합니다. 이것은 나빴다! 정말 나쁘다. 코드에서 버그를 발견하고 수정 한 후 모든 버전을 다시 컴파일했습니다. 하나만 빼고 빌드 과정에서주의가 산만 해져 하나를 잊었습니다. 바이너리가 출시되고 기계가 구축되었으며 하루 후 기계가 응답을 멈췄다는 전화를 받았습니다. 나는 그것을 확인하고 장치가 버스를 잠근 것을 발견했습니다. “하지만 그 버그를 고 쳤어요!”.

제가 고쳤을지 모르지만 그 보드 한 개로 들어 가지 못했습니다. 왜? 클릭 한 번으로 모든 버전을 빌드하는 자동화 된 빌드 프로세스가 없었기 때문입니다.

댓글

• 그리고 커피를 마시 며 빌드 스크립트가 실행 중입니다!

만약 당신이 원하는 것이 빌드 스크립트는 거의 목적이 없습니다 (프로젝트에 Makefile가 표시되면 ). 문제는-사소하지 않은 프로젝트는 일반적으로 그 이상을 필요로합니다. 최소한”일반적으로 라이브러리를 추가하고 (프로젝트가 성숙됨에 따라) 빌드 매개 변수를 구성해야합니다.

IDE는 일반적으로 최소한 구성 가능하지만 이제 빌드 프로세스는 IDE 특정 옵션에 의존합니다. Eclipse 를 사용하는 경우 Alice는 NetBeans 를 선호하고 Bob은

IntelliJ IDEA , 구성을 공유 할 수 없습니다. 사용자 중 한 명이 소스 제어에 변경 사항을 푸시하면 IDE에서 생성 한 구성 파일을 수동으로 편집해야합니다. 다른 개발자에게 알리거나 다른 개발자에게 “직접 수행하도록 알립니다 (즉, IDE 구성이 일부 IDE에 대해 잘못된 커밋이 있음을 의미합니다 …).

또한해야합니다. 팀에서 사용하는 모든 IDE에서 이러한 변경을 수행하는 방법을 파악하고 그중 하나가 특정 설정을 지원하지 않는 경우 …

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

모든 개발자가 동일한 IDE를 사용하도록하더라도 빌드를 설득 할 수 있기를 바랍니다. 사용하는 서버 …

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

마지막으로-빌드 시스템은 단순히 프로젝트를 빌드하는 것 이상으로 좋습니다. 팀의 모든 사람이 수행해야 할 다른 작업을 수행하도록 시스템을 프로그래밍 할 수 있습니다. Ruby on 예를 들어 Rails 에는 데이터베이스 마이그레이션 실행, 임시 파일 정리 등을위한 빌드 시스템 작업이 있습니다. 이러한 작업을 빌드 시스템에 배치하면 팀의 모든 구성원이 일관되게 작업을 수행 할 수 있습니다.

댓글

• 이것이 ‘ 단지 다른 IDE의 문제가 아닙니다. 일부 개발자는 모든 유형의 IDE를 싫어하고 싫어합니다.
• @DavidHammen ‘이 개발자 중 한 명입니다 (하지만 ‘ 내 Vim을 너무 어렵게 구성했지만 ‘ IDE로 전환했을 가능성이 있습니다 …) 해당 단락을 작성하는 동안 자동으로 ” 편집자 IDE에 대한 고정 장치가 내 대답의 중요한 부분이라고 생각하기 때문에 IDE로 수정해야했습니다. 질문자는 분명히 IDE 세계에서 왔으며 적절한 IDE가 없을 때 강제로 수행해야하는 작업 인 IDE없는 개발에 대해 질문합니다. 이 답변의 요점은 IDE 사용자로 구성된 팀에게도 빌드 시스템이 얼마나 유익한지를 보여주는 것입니다.
• 저도 그 개발자 중 한 명입니다. 저는 ‘ 손가락이 키보드를 떠나지 않도록하고 싶습니다. 그렇게하면 내 사고 과정이 중단됩니다.
• 동의하지 않습니다. 나는 IDE를 선호합니다. 이름, 쉬운 조회, 리팩토링, 멋진 UI에 신경 쓰지 않아도됩니다. 즉, IDE가 sed ack 등으로 할 수있는 작업을 수행 할 수 있다면이를 사용합니다.
• 요점은 팀의 모든 개발자가 원하는대로 빌드 스크립트를 사용할 수 있다는 것입니다. IDE ‘의 빌드 기능을 사용하면 모든 사람이 IDE를 사용하도록 할뿐만 아니라 프로젝트가 구성된 매우 특정한 IDE를 사용해야합니다 (여러 IDE와 그 동기화를위한 행운을 빕니다 …)

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

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

요즘에는 모두 MSBuild ,하지만 여전히 IDE에 의해 직접 실행됩니다.

따라서 명령 줄을 사용하는 이유는 소스로 바로 이동하고 중간 사람은 건너 뛰기 때문입니다. 업데이트되었거나 지속적 통합 (CI) 역할을하는 헤드리스 서버에서 원치 않거나 필요하지 않은 많은 종속성이 필요한 중개자 서버.

또한 스크립트는 설계된 일반적인 개발자 지향 단계보다 더 많은 작업을 수행합니다.예를 들어, 빌드 후 바이너리를 패키징하여 특별한 위치에 복사하거나, 설치 프로그램 패키지를 만들거나, 문서 도구를 실행할 수 있습니다. 개발자 컴퓨터에서 무의미한 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입니다. 전화 개발자이며 Google 서비스 API (대부분 Google지도)를 lot 을 사용합니다.

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

개발자 콘솔에 수십 개의 키 저장소를 추가하고 관리하는 대신,이 중 하나만 실제로 앱을 업데이트하는 데 사용할 수 있습니다. 보안 저장소에이 키 저장소를 포함합니다. Gradle을 사용하여 디버그또는 출시를 위해 빌드 할 때 사용할 키 저장소를 Android 스튜디오에 정확히 알려줍니다. 이제 Google 개발자 콘솔에 두 개의 키 저장소를 추가하기 만하면됩니다. 하나는 “디버그”용이고 다른 하나는 “릴리스”용이며, 모든 팀원은 개발자로 이동하지 않고도 저장소를 복제하고 개발에 바로 들어갈 수 있습니다. 콘솔을 열고 특정 키 저장소의 SHA 해시를 추가하거나 관리하도록 합니다. 이렇게하면 각 팀원에게 서명 키 저장소의 사본을 제공하는 추가 이점이 있습니다. 즉, 제가 부재 중이고 업데이트가 예정된 경우 팀원이 매우 짧은 지침 목록 만 따라하면됩니다.

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

빌드 스크립트 장점 :

• 변경 사항은 코드처럼 보입니다 ( 예를 들어, git diff 명령에서), 대화 상자의 다른 확인 옵션과는 다릅니다.

• 간단한 빌드보다 더 많은 출력 생성

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

• 프로젝트 문서 생성 (doxygen 기반)
• 빌드
• 단위 테스트 실행
• 단위 테스트 범위 보고서 생성
• 바이너리를 릴리스 아카이브에 압축
• 내부 릴리스 노트 생성 ( “git log”메시지 기반 )
• 자동 테스트

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

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