Последние 4 года я программировал с помощью Eclipse (для Java) и Visual Studio Express (для C #). Упомянутые IDE всегда, казалось, предоставляли все возможности, которые мог запросить программист (конечно, связанные с программированием).
В последнее время я слышал о чем-то, что называется «инструменты сборки». Я слышал, что они используются почти во всех реальных разработках. Какие именно? Какие проблемы они призваны решать? Почему я не нуждался в них последние четыре года? Являются ли они своего рода урезанными IDE из командной строки?
Инструменты сборки обычно предназначены для преобразования исходного кода в двоичные файлы - они организуют исходный код, устанавливают флаги компиляции, управляют зависимостями ... некоторые из них также интегрируются с запущенным модульным тестом, выполнением статического анализа, созданием документации.
Eclipse или Visual Studio также являются системами сборки (но в большей степени IDE), а для Visual Studio это базовая msbuild для анализа файлов проекта Visual Studio под капотом.
Происхождение всех систем сборки похоже на знаменитую «марку».
Существуют системы сборки для разных языков:
Обычно системы сборки либо с использованием подходящего для домена языка (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
источник