빌드 도구 란 무엇입니까?

빌드 도구 란 무엇입니까?

---

지난 4 년 동안 Eclipse (Java) 및 Visual Studio Express (C #)를 사용하여 프로그래밍했습니다. 언급 된 IDE는 항상 프로그래머가 요청할 수있는 모든 시설을 제공하는 것처럼 보였다 (물론 프로그래밍과 관련됨).

최근에 나는 "빌드 툴"이라는 것을 들었습니다. 나는 그들이 거의 모든 종류의 실제 세계 개발에 사용된다고 들었습니다. 그들은 정확히 무엇입니까? 그들은 어떤 문제를 해결하기 위해 고안 되었습니까? 지난 4 년 동안 어떻게 필요하지 않았습니까? 그것들은 일종의 명령 줄로 IDE를 제거합니까?

---

빌드 도구 란 무엇입니까?

빌드 도구는 소스 코드에서 실행 가능한 응용 프로그램 (예 : .apk for android app)을 자동으로 만드는 프로그램입니다. Building은 코드를 컴파일, 링크 및 패키징하여 사용 가능하거나 실행 가능한 형태로 통합합니다.

기본적으로 빌드 자동화는 소프트웨어 개발자가 다음과 같은 일상 활동에서 수행하는 다양한 작업을 스크립팅하거나 자동화하는 작업입니다.

1. 의존성 다운로드.
2. 소스 코드를 이진 코드로 컴파일
3. 이진 코드를 패키징합니다.
4. 테스트 실행
5. 프로덕션 시스템에 배포

빌드 도구 또는 빌드 자동화를 사용하는 이유는 무엇입니까?

소규모 프로젝트에서는 개발자가 빌드 프로세스를 수동으로 호출하는 경우가 많습니다. 이는 구축해야 할 대상, 순서 및 종속성을 추적하기가 어려운 대규모 프로젝트에는 실용적이지 않습니다. 자동화 도구를 사용하면 빌드 프로세스의 일관성을 높일 수 있습니다.

다양한 빌드 도구 사용 가능 (네이밍 만 가능) :

1. Java의 경우-Ant, Maven, Gradle.
2. .NET 프레임 워크-NAnt
3. c #-MsBuild.

자세한 내용은 다음 링크를 참조하십시오.

1. 자동화 구축

2. 빌드 자동화 소프트웨어 목록

감사.

---

빌드 도구는 빌드를 관리하고 구성하는 도구이며, 특히 프로젝트가 서로 연결된 경우 많은 프로젝트가있는 환경에서 매우 중요합니다. 그들은 다양한 사람들이 다양한 프로젝트를 수행하는 곳에서는 아무것도 깨뜨리지 않도록합니다. 그리고 변경을 할 때 아무것도 깨지지 않도록합니다.

이전에 들어 보지 못한 이유는 이전에 상업 환경에서 일하지 않았기 때문입니다. 상용 소프트웨어 환경에서 특히 소프트웨어 하우스에서 작업하는 경우 발생할 수있는 많은 것들이 있습니다.

다른 사람들이 말했듯이, 당신은 그것들을 사용하고 있지만, 당신은 아마 일반적인 상업적 작업 방식과 다른 방식으로 일하고 있었기 때문에 그것들을 고려할 필요가 없었습니다.

---

빌드 도구는 일반적으로 명령 줄에서 IDE 내부에서 실행되거나 완전히 분리되어 실행됩니다.

아이디어는 코드 컴파일 및 패키징 작업을 생성, 디버깅 등으로부터 분리하는 것입니다.

빌드 도구는 명령 또는 IDE 내에서 실행할 수 있으며 둘 다 사용자가 트리거합니다. 리포지토리와 깨끗한 빌드 머신에서 코드를 확인한 후 지속적인 통합 도구로 사용할 수도 있습니다.

make는 C / C ++ 구축을 위해 * nix 환경에서 사용 된 초기 명령 도구였습니다.

Java 개발자로서 가장 널리 사용되는 빌드 도구는 Ant 및 Maven입니다. 둘 다 IntelliJ, Eclipse 또는 NetBeans와 같은 IDE에서 실행될 수 있습니다. Cruise Control 또는 Hudson과 같은 지속적인 통합 도구로도 사용할 수 있습니다.

---

빌드 도구는 일반적으로 소스 코드를 바이너리로 변환하는 것입니다. 소스 코드를 구성하고, 컴파일 플래그를 설정하고, 종속성을 관리합니다. 일부 도구는 단위 테스트 실행, 정적 분석, 문서 생성과도 통합됩니다.

Eclipse 또는 Visual Studio는 빌드 시스템이지만 더 많은 IDE이며 Visual Studio의 경우 Visual Studio 프로젝트 파일을 구문 분석하는 기본 msbuild입니다.

모든 빌드 시스템의 기원은 유명한 'make'와 같습니다.

다른 언어를위한 빌드 시스템이 있습니다 :

1. C ++ : make, cmake, premake
2. 자바 : ant + ivy, maven, gradle
3. C # : msbuild

일반적으로 적절한 도메인 특정 언어 (make, cmake) 또는 xml (ant, maven, msbuild)을 사용하여 빌드를 지정하여 시스템을 빌드하십시오. 현재 트렌드는 실제 스크립팅 언어를 사용하여 프리 메이크 용 루아, 그레 비용 그루비와 같은 빌드 스크립트를 작성하고 있습니다. API (빌드 DSL).

---

빌드 프로세스는 일부 빌드 도구를 사용하여 오류에 대해 소스 코드를 컴파일하고 빌드 (프로젝트의 실행 가능한 버전)를 만드는 프로세스입니다. 우리 (주로 개발자)는 소스 코드를 수정하고 빌드 프로세스가 발생하도록 해당 코드를 체크인합니다. 빌드 프로세스 후 두 가지 결과가 나타납니다. 1. PASSES를 빌드하고 프로젝트의 실행 버전을 얻습니다 (빌드 준비 완료). 2. 실패하고 특정 오류가 발생하고 빌드가 작성되지 않습니다.

빌드 프로세스에는 다음과 같은 다양한 유형이 있습니다. 1. 야간 빌드 2. 게이트 빌드 3. 지속적인 통합 빌드 등

빌드 도구는 빌드 작성 프로세스를 도와주고 자동화합니다.

*So in Short Build is a Version of Software in pre-release format used by the Developer or Development team to gain confidence for the final result of their Product by continuously monitoring their Product and solving any issues early during the development process.*

---

These are different types of processes by which you can get your builds done.

1. Continuous Integration build: In this mainly developers check-in their code and right after their check-in a build initiates for building of the recent changes so we should know whether the changes done by the developer has worked or not right after the check-in is done. This is preferred for smaller projects or components of the projects. In case where multiple teams are associated with the project or there are a large no. of developers working on the same project this scenario becomes difficult to handle as if there are 'n' no. of check-in’s and the build fails at certain points it becomes highly difficult to trace whether all the breakage has occurred because of one issue or with multiple issues so if the older issues are not addressed properly than it becomes very difficult to trace down the later defects that occurred after that change. The main benefit of these builds is that we get to know whether a particular check-in is successful or not.

2. Gated check-in builds: In this type of check in a build is initiated right after the check in is done keeping the changes in a shelve sets. In this case if the build succeeds than the shelve-set check-in gets committed otherwise it will not be committed to the Team Foundation Server. This gives a slightly better picture from the continuous integration build as only the successful check-in's are allowed to get committed.

3. Nightly builds: This is also referred as Scheduled builds. In this case we schedule the builds to run for a specific time in order to build the changes. All the previous uncommitted changes from the last build are built during this build process. This is practiced when we want to check in multiple times but do not want a build every time we check in our code so we can have a fixed time or period in which we can initiate the build for building of the checked-in code.

The more details about these builds can be found at the below location.

Gated-check in Builds

Continuous Integration Builds

Nightly Builds

---

You have been using them - IDE is a build tool. For the command line you can use things like make.

People use command line tools for things like a nightly build - so in the morning with a hangover the programmer has realised that the code that he has been fiddling with with the latest builds of the libraries does not work!

---

"...it is very hard to keep track of what needs to be built" - Build tools does not help with that all. You need to know what you want to build. (Quoted from Ritesh Gun's answer)

"I heard they're used almost in all kind of real-world development" - For some reason, software developers like to work in large companies. They seem to have more unclear work directives for every individual working there.

"How come I never needed them in past four years". Probably because you are a skilled programmer.

Pseudo, meta. I think build tools do not provide any really real benefit at all. It is just there to add a sense of security arising from bad company practices, lack of direction - bad software architectural leadership leading to bad actual knowledge of the project. You should never have to use build tools(for testing) in your project. To do random testing with a lack of knowledge of the software project does not give any sort of help at all.

You should never ever add something to a project without knowing it's purpose, and how it will work with the other components. Components can be functional separate, but not work together. (This is the responsibility of the software architect I assume).

What if 4-5 components are added into the project. You add a 6th component. Together with the first added component, it might screw up everything. No automatic would help to detect that.

There is no shortcut other than to think think think.

Then there is the auto download from repositories. Why would you ever want to do that? You need to know what you download, what you add to the project. How do you detect changes in versions of the repositories? You need to know. You can't "auto" anything.

What if we were to test bicycles and baby transports blindfolded with a stick and just randomly hit around with it. That seems to be the idea of build tool testing.

I'm sorry there are no shortcut https://en.wikipedia.org/wiki/Scientific_method and https://en.wikipedia.org/wiki/Analysis

참고URL : https://stackoverflow.com/questions/7249871/what-is-a-build-tool