Что такое инструмент сборки?

Последние 4 года я программировал с помощью Eclipse (для Java) и Visual Studio Express (для C #). Упомянутые IDE всегда, казалось, предоставляли все возможности, которые мог запросить программист (конечно, связанные с программированием).

В последнее время я слышал о чем-то, что называется «инструменты сборки». Я слышал, что они используются почти во всех реальных разработках. Какие именно? Какие проблемы они призваны решать? Почему я не нуждался в них последние четыре года? Являются ли они своего рода урезанными IDE из командной строки?

Что такое инструменты сборки?

Инструменты сборки - это программы, которые автоматизируют создание исполняемых приложений из исходного кода (например, .apk для приложения Android). Сборка включает в себя компиляцию, связывание и упаковку кода в пригодную для использования или исполняемую форму.

По сути, автоматизация сборки - это процесс написания сценариев или автоматизации широкого спектра задач, которые разработчики программного обеспечения выполняют в своей повседневной деятельности, например:

1. Скачивание зависимостей.
2. Компиляция исходного кода в двоичный код.
3. Упаковка этого двоичного кода.
4. Запуск тестов.
5. Развертывание в производственных системах.

Почему мы используем инструменты сборки или автоматизацию сборки?

В небольших проектах разработчики часто запускают процесс сборки вручную. Это непрактично для больших проектов, где очень сложно отслеживать, что нужно построить, в какой последовательности и какие зависимости существуют в процессе сборки. Использование инструмента автоматизации позволяет сделать процесс сборки более последовательным.

Доступны различные инструменты сборки (названы только несколько):

1. Для java - Ant, Maven, Gradle.
2. Для .NET framework - NAnt
3. c # - MsBuild.

Для дальнейшего чтения вы можете перейти по следующим ссылкам:

1. Автоматизация сборки

2. Список программного обеспечения для автоматизации сборки.

Спасибо.

Инструменты сборки - это инструменты для управления и организации ваших сборок, и они очень важны в средах с большим количеством проектов, особенно если они взаимосвязаны. Они служат для того, чтобы гарантировать, что там, где над разными проектами работают разные люди, они ничего не сломают. И чтобы убедиться, что когда вы вносите свои изменения, они тоже ничего не ломают.

Причина, по которой вы не слышали о них раньше, заключается в том, что вы раньше не работали в коммерческой среде. Существует множество вещей, с которыми вы, вероятно, не сталкивались в коммерческой среде, особенно если вы работаете в разработчиках программного обеспечения.

Как говорили другие, вы использовали их, однако вам не нужно было их учитывать, потому что вы, вероятно, работали иным способом, нежели обычный коммерческий способ работы.

Инструменты сборки обычно запускаются из командной строки либо внутри IDE, либо полностью от нее.

Идея состоит в том, чтобы отделить работу по компиляции и упаковке вашего кода от создания, отладки и т. Д.

Инструмент сборки может запускаться по команде или внутри IDE, и то и другое запускается вами. Они также могут использоваться инструментами непрерывной интеграции после проверки вашего кода из репозитория на чистой машине сборки.

make был ранним командным инструментом, который использовался в средах * nix для создания C / C ++.

Как разработчик Java, наиболее популярными инструментами сборки являются Ant и Maven. Оба могут быть запущены в IDE, таких как IntelliJ, Eclipse или NetBeans. Их также можно использовать в таких инструментах непрерывной интеграции, как круиз-контроль или Hudson.

Инструменты сборки обычно предназначены для преобразования исходного кода в двоичные файлы - они организуют исходный код, устанавливают флаги компиляции, управляют зависимостями ... некоторые из них также интегрируются с запущенным модульным тестом, выполнением статического анализа, созданием документации.

Eclipse или Visual Studio также являются системами сборки (но в большей степени IDE), а для Visual Studio это базовая msbuild для анализа файлов проекта Visual Studio под капотом.

Происхождение всех систем сборки похоже на знаменитую «марку».

Существуют системы сборки для разных языков:

1. C ++: make, cmake, premake
2. Java: муравей + плющ, maven, gradle
3. C #: msbuild

Обычно системы сборки либо с использованием подходящего для домена языка (make, cmake), либо xml (ant, maven, msbuild) для определения сборки. Текущая тенденция заключается в использовании реального языка сценариев для написания сценария сборки, такого как lua ​​для premake и groovy для gradle, преимущество использования сценария в том, что он намного более гибкий, а также позволяет вам придумать набор стандартных API (как сборка DSL).

Процесс сборки - это процесс компиляции исходного кода для устранения любых ошибок с использованием некоторых инструментов сборки и создания сборок (которые являются исполняемыми версиями проекта). Мы (в основном разработчики) вносим некоторые изменения в исходный код и проверяем этот код для выполнения процесса сборки. После процесса сборки он дает два результата: 1. Либо сборка ПРОХОДИТ, и вы получаете исполняемую версию вашего проекта (сборка готова). 2. Он терпит неудачу, вы получаете определенные ошибки и сборка не создается.

Существуют различные типы процесса сборки, например: 1. Ночная сборка 2. Закрытая сборка 3. Сборка с непрерывной интеграцией и т. Д.

Инструменты сборки помогают автоматизировать процесс создания сборок.

* Таким образом, in Short Build - это версия программного обеспечения в формате предварительной версии, используемая разработчиками или командой разработчиков, чтобы получить уверенность в конечном результате своего продукта путем постоянного мониторинга своего продукта и решения любых проблем на ранних этапах процесса разработки. *

Это разные типы процессов, с помощью которых вы можете создавать свои сборки.

1. Построение непрерывной интеграции:В этом случае разработчики, в основном, регистрируют свой код, и сразу после их регистрации запускается сборка для создания последних изменений, поэтому мы должны знать, сработали ли изменения, сделанные разработчиком, сразу после завершения регистрации. Это предпочтительно для небольших проектов или компонентов проектов. В случае, если с проектом связано несколько команд или большой нет. разработчиков, работающих над одним и тем же проектом, с этим сценарием трудно справиться, как будто их нет. регистрации и сборки не удается в определенные моменты, становится очень сложно отследить, все ли поломки произошли из-за одной проблемы или из-за нескольких проблем, поэтому, если более старые проблемы не решаются должным образом, становится очень трудно отследить более поздние дефекты, возникшие после этого изменения.

2. Сборки с закрытой регистрацией: в этом типе проверки сборка инициируется сразу после завершения проверки, сохраняя изменения в наборах полок. В этом случае, если сборка завершается успешно, то фиксация набора полок фиксируется, иначе она не будет зафиксирована на Team Foundation Server. Это дает немного лучшую картину по сравнению с непрерывной интеграционной сборкой, поскольку только успешные регистрации могут быть зафиксированы.

3. Ночные сборки: это также называется запланированной сборкой. В этом случае мы планируем запуск сборок на определенное время, чтобы внести изменения. Все предыдущие незафиксированные изменения из последней сборки создаются во время этого процесса сборки. Это практикуется, когда мы хотим проверять несколько раз, но не хотим, чтобы сборка происходила каждый раз, когда мы проверяем наш код, поэтому у нас может быть фиксированное время или период, в течение которого мы можем инициировать сборку для сборки проверенного кода.

Более подробную информацию об этих сборках можно найти по указанному ниже адресу.

Закрытая регистрация в сборках

Сборки с непрерывной интеграцией

Ночные сборки

Вы их использовали - IDE - это инструмент для сборки. Для командной строки вы можете использовать такие вещи, как make.

Люди используют инструменты командной строки для таких вещей, как ночная сборка - так что утром с похмелья программист понял, что код, с которым он возился с последними сборками библиотек, не работает!

«... очень сложно отслеживать, что нужно построить» - Инструменты сборки не помогают со всем этим. Вам нужно знать, что вы хотите построить. (Цитата из ответа Ritesh Gun)

«Я слышал, что они используются почти во всех видах реальной разработки» - разработчики программного обеспечения по какой-то причине любят работать в крупных компаниях. Кажется, у них более нечеткие рабочие инструкции для каждого человека, работающего там.

«Как получилось, что они мне не нужны последние четыре года». Наверное, потому, что вы опытный программист.

Псевдо, мета. Я думаю, что инструменты сборки не приносят никакой реальной пользы. Это просто для того, чтобы добавить чувство безопасности, возникающее из-за плохой практики компании, отсутствия направления - плохого лидерства в архитектуре программного обеспечения, ведущего к плохому фактическому знанию проекта. Вам никогда не придется использовать инструменты сборки (для тестирования) в своем проекте. Проведение выборочного тестирования при незнании программного проекта вообще не поможет.

Вы никогда не должны добавлять что-либо в проект, не зная его цели и того, как это будет работать с другими компонентами. Компоненты могут работать по отдельности, но не работать вместе. (Я полагаю, это ответственность архитектора программного обеспечения).

Что делать, если в проект добавлено 4-5 компонентов. Вы добавляете шестой компонент. Вместе с первым добавленным компонентом он может все испортить. Никакая автоматика не поможет это обнаружить.

Нет другого пути, кроме как думать, думать, думать.

Затем есть автоматическая загрузка из репозиториев. Зачем тебе это нужно? Вам нужно знать, что вы скачиваете, что добавляете в проект. Как вы обнаруживаете изменения в версиях репозиториев? Ты должен знать. Вы не можете ничего "автоматизировать".

Что, если бы мы тестировали велосипеды и детские коляски с завязанными глазами палкой и просто случайным образом ударяли ею. Похоже, в этом заключается идея тестирования инструментов сборки.

Мне очень жаль, что нет ярлыка https://en.wikipedia.org/wiki/Scientific_method и https://en.wikipedia.org/wiki/Analysis