Строительная инженерия имеет решающее значение для строительных норм. Тем не менее, хотя это важно, это сложно и разнообразно. Каждый язык программирования обычно имеет свой собственный набор инструментов. Кроме того, существуют различия в наборе инструментов для каждой платформы операционной системы, на которой вы работаете.
Какими бы важными ни были инструменты сборки для процесса разработки программного обеспечения, найти информацию по этой теме в Интернете на удивление сложно. И хотя вы регулярно будете слышать фразу «Я ненавижу ‹вставьте название инструмента сборки›, но все остальные еще хуже», в плане улучшения или развития технологии сборки сделано немногое.
В ActiveState мы сами боролись за проектирование для языков с открытым исходным кодом в течение последних 20 лет. От конфликтов зависимостей до ошибок компилятора, от уязвимостей библиотек до несовместимости систем — мы видели все, что приводит к сбою сборки и задержке выпуска в различных операционных системах и архитектурах.
В результате мы стремимся помочь организациям устранить проблемы, связанные с созданием, обновлением, исправлением и управлением зависимостями их языков с открытым исходным кодом. Последовательные, воспроизводимые, стандартизированные сборки — наша цель создать стандарт де-факто для проектирования зданий.
Как правило, четыре проблемы в конвейере сборки возникают из-за:
- зависимости;
- отсутствие воспроизводимости: участники жизненного цикла разработки программного обеспечения (SDLC) постоянно сталкиваются с проблемами при получении согласованной языковой версии;
- сохранение кода «в соответствии со спецификацией»: лицензии, исправления, обновления, уязвимости безопасности и т. д.;
- технический долг: если обновления не выполняются регулярно, вы в конечном итоге получите систему, которую не осмелитесь обновить.
Частью решения проблем, с которыми сталкиваются предприятия в процессе сборки, было более глубокое понимание болевых точек. Поэтому мы провели опрос среди 1400 разработчиков относительно проблем, с которыми они столкнулись в этом году при работе с открытым исходным кодом, чтобы установить наш базовый уровень — нажмите здесь, если хотите получить опубликованный отчет.
Одним из ключевых выводов опроса стала нагрузка на разработчиков. Более 75% опрошенных разработчиков заявили, что они тратят хотя бы часть своего времени на управление зависимостями и инструментами разработки. Объедините это число с более чем 50% респондентов, заявивших, что они начинают новый проект не реже одного раза в квартал.
Конечным результатом является то, что разработчикам необходимо уделять много времени созданию новой версии языка с открытым исходным кодом для каждого запущенного проекта и последующему поддержанию языкового распределения для каждой команды в организации. Это время приводит к значительным затратам для предприятия.
Но что, если бы вы могли автоматизировать сборку своих языков с открытым исходным кодом? Если бы вы могли выбрать только те пакеты, которые вам нужны, платформу, на которой вы хотите развернуться, а затем автоматически обновлять этот языковой дистрибутив, когда выходят новые версии или обнаруживаются уязвимости?
Вы получите согласованную сборку, которую можно непрерывно и быстро распространять среди всех членов команды в любой из ваших сред SDLC: разработки, тестирования и производства.
И если у вас есть согласованная версия вашего языка, у всех в вашей команде есть все необходимые компоненты. Потому что, когда вы строите язык, вы также строите зависимости и создаете среду, в которой вы отбрасываете код.
Результатом является согласованная среда сборки от разработки до CI/CD и до производства, где вам больше не нужно слышать «ну, это работает на МОЕЙ машине». Более того, вы бы ускорили время сборки.
Другие системы сборки предназначены только для компиляции кода и предполагают, что у вас уже установлены все зависимости. Мы верим, что вы можете взять язык, рассказать нам, каковы ваши зависимости, и со временем мы будем управлять им и отслеживать его. У вас может быть свой контрольный список, инвентарь и вики все в одном. Ваша среда готова, но что еще лучше, у вас будет список ваших активов, чтобы вы могли проводить аудит и «инвентаризацию» по своему усмотрению.
Это значение экспоненциально выше для предприятий-полиглотов. Каждый язык работает по-своему, и 4 ключевые проблемы вашего конвейера сборки (см. выше) увеличиваются с каждым новым добавленным языком.
И недостаточно просто автоматизировать проектирование зданий. Должен быть систематический, стандартизированный и унифицированный подход, учитывающий различия в используемых вами языках, но использующий согласованный рабочий процесс или процесс для вывода типа сборки, который вам нужен для вашего проекта или варианта использования.
Именно так мы хотели бы, чтобы строительная инженерия развивалась. Непрерывные воспроизводимые сборки для обеспечения непрерывного развертывания и высвобождения времени разработчиков, а также предоставления предприятиям контроля над рисками, связанными с их открытым исходным кодом.
Вы уменьшите накладные расходы на сборку и избавитесь от обслуживания выделенных инструментов и инфраструктуры, чтобы команда могла лучше тратить свое время на работу с высокой ценностью.
ActiveState подробно рассмотрит эти проблемы на предстоящем веб-семинаре с DevOps.com. Сохраните свое место для нашей живой дискуссии об развивающейся роли инженерии сборки в управлении открытым исходным кодом.
