수년간 Java를 프로그래밍하고 최근에는 Scala를 개발할 때 Ant, Maven, Gradle 또는 Java 용 빌드 도구를 사용한 적이 없습니다. 내가 일한 모든 곳에서 빌드 관리자가 모든 것을 처리했습니다. 개발 및 단위 테스트를 위해 IDE를 사용하여 로컬로 컴파일 한 다음 소스 코드를 확인하고 필요한 것을 수행 한 빌드 관리자에게 알립니다. 공유 환경을 위해 모든 사람의 파일을 컴파일하십시오.

이제 계약을 맺고 나 자신의 자체 자금 지원 프로젝트를 진행하고 있으며 실제로 돈을 벌 수있을 정도로 좋은 시점에 도달하고 있습니다. 잠재적 인 투자자가 줄을 서서 몇 주 안에 베타 버전을 보여줄 계획입니다.

그러나 IDE에서 빌드 버튼을 클릭하면 Jar 파일이 생성되고 제대로 작동합니다. 물론, 기존의 지혜는 내가 직접 Ant / Maven / Gradle 스크립트를 작성하고 IDE 대신이 스크립트를 사용해야한다는 것을 암시하지만 내 상황에서 그 자체의 장점은 무엇입니까 (혼자 작업)?

이 빌드 도구를 사용하는 방법에 대한 몇 가지 정보를 읽었으며 한 번의 클릭으로 IDE가 수행하는 작업에 대해 수백 줄의 XML (또는 Groovy 또는 기타)을 작성하는 것처럼 보입니다 (IDE 생성 프로젝트의 Ant XML은 700 줄 이상입니다. 오류가 발생하기 쉽고 시간이 많이 걸리며 내 상황에는 불필요합니다. 학습 곡선은 말할 것도없고, 제품을 사람들에게 보여주기 위해 내가하고있는 다른 모든 작업에서 시간을 빼앗아 갈 것입니다.

Ant와 달리 Maven을 사용하는 것이 좋습니다. IDE가 한 번의 클릭으로 프로젝트를 빌드 할 수 있다면 Maven은 거의 사용자 정의 구성없이 프로젝트를 빌드 할 수도 있습니다.

질문에 대답하기 위해 배포 프로세스를 단순화하는 것이 구체적인 예입니다. 로컬로 배포 가능 배포판을 작성하는 경우 프로덕션 시스템에 해당 배포 가능 구성 요소를 수동으로 배포해야하며, 배포 준비를 위해 프로덕션 시스템에서 약간의 수동 구성을 수행해야 할 수도 있습니다 (Tomcat 설치). , 또는 응용 프로그램에 필요한 종속성 및 리소스를 복사). 시간이 오래 걸리고 업데이트 배포가 지루한 수동 프로세스가 될 수 있습니다. 또한 프로덕션 플랫폼과 개발 환경 간의 사소한 구성 차이로 인해 불명확하고 추적하기 어려운 오류가 발생할 수 있습니다.

어쨌든,이 수동 준설을 제거하기 위해해야 ​​할 일은 Maven으로 빌드하도록 프로젝트를 구성 pom.xml하고 (Java web-app의 경우) 필요한 모든 정보로 파일을 구성 하여 올바른 Tomcat 버전으로, 로컬로 설치하고, 올바른 Tomcat 구성 파일을 설정하고, 프로젝트 종속성 및 프로젝트 WAR 파일 자체를 배치 한 다음 Tomcat을 시작하십시오. 그런 다음 .batMaven을 사용하여 서버를 빌드하고 시작 하는 간단한 쉘 스크립트 (및 Windows 용 버전)를 작성합니다.

mvn clean install cargo:start -Dcargo.maven.wait=true

따라서 개발 환경에 배포 가능한 제품을 패키징하고 수동으로 프로덕션 환경으로 푸시하는 대신 버전 관리 시스템에서 프로덕션 서버로 동기화 한 다음 프로덕션 시스템 자체를 빌드, 설치 및 실행하기 만하면됩니다. 배포 가능 (및 개발 시스템에서 수행 되는 방식 과 동일한 방식으로 수행하여 플랫폼 별 오류 또는 구성 오류 가능성을 최소화 함). 그리고 개발 환경이나 프로덕션 환경에서 서버를 구축하고 시작하기 위해해야 ​​할 일은 다음과 같습니다.

./startServer.sh #or startServer.bat for Windows

프로덕션 환경에 업데이트를 배포하려면 프로세스는 다음과 같습니다.

1. 실행중인 서버 인스턴스가 있으면 중지하십시오.
2. 를 실행하십시오 svn update -r<target_release_revision>.
3. 를 실행하십시오 ./startServer.sh.

IDE를 사용하여 배포 가능한 파일을 빌드하는 경우 간단하고 기억하기 쉬우 며 전혀 할 수 없습니다. 또한 롤백이 필요한 경우 마지막으로 성공한 배포로 되돌릴 수 있습니다.

이 접근 방식으로 인해 배포 및 구성 프로세스를 수동으로 관리하는 데 드는 시간을 절약 할 수도 없었습니다.

물론 귀하의 질문에 대한 또 다른 대답은 자동 종속성 관리이지만 다른 답변으로 이미 다루어 져 있다고 생각합니다.

코드가 소스 제어에있는 한 IDE를 사용하여 배포 가능 파일을 만드는 것이 좋습니다.

한 사람이 쇼핑하는 동안 제품에 새로운 기능을 추가하거나 빌드 스크립트를 작성하는 데 시간이 더 많이 소요됩니까? 빌드 스크립트를 작성하지 않는 것이 있습니다.

물론 혼자서 일할 때의 이점을보기가 더 어렵습니다. 개인적으로 저는 많은 솔로 프로젝트를 수행했으며 빌드 스크립트를 작성했을뿐만 아니라 Jenkins와 같은 CI 서버 설정 문제를 겪었습니다.

물론 오버 헤드가 있는데 왜 가치가 있습니까?

• IDE (또는 외부에서 실행하는 경우 컴퓨터)와 연결되지 않은 재현 가능한 빌드. 빌드 서버가이를 실행하면 다른 머신이이를 실행할 수 있습니다.
• 재미는 구축 및 단위 테스트 후 시작 (그런데 : 당신이 있는지 ? 모든 커밋 전에 가끔 잊어 테스트). 문서 생성, 설치 프로그램 작성, 선호하는 코드 분석 도구 실행
• 자주 사용하는 CI 서버를 통해 시간이 지남에 따라 코드 적용 범위, 단위 테스트 실패 등의 그래프를 볼 수 있습니다. IDE가 그렇게합니까?

현재 프로젝트에서 스크립트는 빌드, 정적 분석 도구를 실행하고 js / css, 단위 테스트 및 패키지를 웹 아카이브로 압축합니다. Jenkins는 커밋 후에이를 실행하고 프로젝트를 테스트 서버에 배포합니다.

나는 이것을 설정하는 데 시간이 걸렸으며 (빌드 스크립트는 아마도 300 줄, 몇 달 동안 만지지 않았 음) 한 사람조차도 가치가 있다고 말할 수 있습니다. 여러 사람에게 필요합니다. 빌드 / 배포 프로세스에 대한 나의 참여는 "hg commit"및 "hg push"명령으로 구성됩니다.

빌드 도구의 장점

그것은 단지 빙산의 일각을 보여주는 간단한 요약이며, 많은 프로젝트, 대규모 프로젝트 및 중대형 팀의 조합과 관련이없는 한이 모든 것의 중요성을 반드시 알지 못할 것입니다. 그러나 믿음이 있고 노력 하면 유익을 얻을 수 있습니다.

개발 라이프 사이클을 촉진하고 다음과 같은 이점을 제공합니다.

• 일관 되고 손쉬운 프로젝트 구성 및 구조
• 프로젝트 전체에서 모범 사례를 재사용 하고 쉽고 빠르게 시작 합니다.
• 여러 빌드를 단일 빌드로 통합
• 자동화 하여 지속적인 통합 프로세스를
• 프로젝트를 다른 사람들과 공유
  • 특정 툴킷 또는 IDE (빌드 시스템 제외)를 사용하지 않고
  • 표준 빌드를 기대하므로 놀라지 않고
• 자동화 및 촉진 유지 보수 제품의를
• 제품 출시 프로세스 자동화

이것을 Maven에 적용하면 ...

자바 세계에서 Maven 을 사용하는 사람들을 위해 이것을 읽으면 각 포인트를 자연스럽게 연관시킬 수 있습니다.

• 메이븐의 구조화 된 프로젝트 컨벤션
• 메이븐 아키 타입
• SCM 및 원자로 빌드로 프로젝트 구체화
• Jenkins / Hudson / Bamboo / 기타 지원 + 통합 테스트 사례에 대한 Maven의 지원
• m2eclipse, 기본 IntelliJ 또는 NetBeans 지원-또는 명령 행의 경우 mvnsh
• 버전 메이븐 플러그인
• maven-release-plugin, buildnumber-maven-plugin 플러그인 및 versions-maven-plugin

물론 Maven (그러나 다른 도구도 포함)은 종속성 관리 기능을 제공 하며, 이는 (팀의 인원 수를 고려하여) 귀하와 SCM을위한 엄청난 시간과 공간 절약 입니다.

모든 상대 :

Maven을 가장 포괄적이고 "배터리 포함"빌드 시스템이라고 생각하기 때문에 Maven을 예로 사용하고 있지만 이것이 반드시 "최고"인 것은 아닙니다. 위에 나열된 모든 확인란에 적합하며, 훌륭한 빌드 시스템을 찾을 때이 목록과 Maven과 비교합니다. 그러나 Maven은 표준화 된 프로세스에서 벗어날 경우 항상 유연하지는 않지만 확장 성이 뛰어납니다. 일반적인 경우 (학습 곡선보다 한 번 앞서서) 제품 아이비를 높이는 것이 아니라, 싸우는 것이 아닙니다.

빌드 도구를 사용해야하는 4 가지 이유는 다음과 같습니다.

• 종속성 처리 (오류 방지)
• 테스트 (변경 사항으로 인해 다른 모듈이 손상되지 않음-테스트하기가 훨씬 쉬움)
• 안전한 커밋
• 로컬 배포 가능 배포 용이 (QA env에서 빌더가 프로젝트 및 해당 종속성을 빌드 할 때까지 기다릴 시간이 없음)

Andrew Hunt와 David Thomas는 Pragmatic Programmer 책 에서 'checkout-build-test-deploy'는 단일 명령이어야한다고 말합니다 (Chapter : Pragmatic Projects). 당신은 썼습니다 ..

잠재적 인 투자자가 줄을 서서 몇 주 안에 베타 버전을 보여줄 계획입니다.

그런 다음 팀이 성장할 것이라고 확신합니다. 자동 테스트 배포 기능을 수행하는 것이 더욱 중요합니다.

보았던 큰 XML (스크립트)은 일반적으로 일회성 작업입니다. 대부분의 경우 동일한 스크립트를 여러 프로젝트에서 사용할 수 있습니다.

프로젝트가 얼마나 큰지는 명확하지 않습니다. 통합 테스트 / 수락 테스트에 많은 CPU / 메모리가 필요한 경우 다른 컴퓨터를 테스트 서버로 사용하는 것이 좋습니다. 소스 코드 / 바이트 코드를 분석하기 위해 다양한 도구를 배포 할 수도 있습니다 .

고독한 개발자에게는 스크립트 빌드와 같은 좋은 프로세스와 구조를 갖는 것이 팀에있을 때보 다 훨씬 중요하다고 주장합니다. 당신이 코너를자를 때 당신을 불러 줄 동료가없는 이유. 빌드 스크립트를 실행하는 CI 서버를 사용하면 타협하지 않는 훌륭한 팀원이 정직하게 유지할 수 있습니다.

코드베이스가 커짐에 따라 테스트 스위트를 추가하려고합니다. 내 경험에 따르면이 작업은 나중에 수행하기보다 빨리 수행해야하며 야간 (또는 무엇이든) 빌드는 매번 모든 테스트를 실행해야합니다. 작게 시작하면 자동 생성 된 XML이 적합 할 것입니다. 다른 것을 깨뜨리는 것을 두려워하여 무언가를 바꾸는 것이 두려운 경우 몇 가지 테스트 사례를 작성하는 것이 좋습니다.

IDE가 아닌 빌드를 사용하면 당시의 방식대로 IDE를 재구성 할 걱정없이 이전 버전을 쉽게 다시 빌드 할 수 있으며, 비 대화식으로 빌드를 수행 할 수 있으므로 사람들이 테스트 할 수 있도록 야간 빌드를 유지하거나 빠르게 찾을 수 있습니다. 테스트 실행을 기억하고 테스트가 완료 될 때까지 기다릴 필요없이 테스트를 중단 한 경우

또한 서버에 대한 ssh와 같은 GUI가 아닌 환경에서 빌드를 수행 할 수 있으며 소프트웨어 빌드 기능의 손실에 대한 걱정없이 IDE를 전환 할 수 있습니다.

일부 빌드 도구는 릴리스 태그 지정 및 배포를 자동화하고 코드 적용 범위 보고서 생성을위한 적절한 기본값을 제공합니다.

더 많은 사람들을 추가 할 때, 빌드 도구는 다른 사람의 열악한 IDE 구성에 취약하지 않도록합니다. 나는 정기적으로 화면 공유를 수행하여 동료의 Eclipse 설치를 수정합니다. 빌드 도구를 사용하지 않기 때문입니다.

그러나 궁극적 인 이유는 수동으로 수행 할 필요가 없기 때문에 수동으로 수행하지 마십시오. 그 밖의 모든 것이 빠집니다.