История изменений

devops/sre и без Go может это сделать, на чистой этой вашей жаве

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

первый квест в том, чтобы вообще собрать этот код и получить релизные артефакты для развертывания. Для примера, когда нам передали этот код для улучшения, мы (разработчики-программисты) в течение двух недель учились только собирать и запускать этот код - и по-моему, так и не научились.

Второй квест в том, чтобы обмазать релизные артефакты скриптами на энсибле, пайтоне и баше, и совместить это с ченжами в архитектуре приложения инфраструктуре. Третий - в написании толстенной инструкции для админов (админы обычно не хотят разбираться в скриптах, им нужно вордовский файл на триста страниц, в котором описываются команды, которые нужно выполнить в командной строке - иначе говоря, плейбуки, описанные «человеческим» языком). На выходе всех квестов получается готовая поставка для развертывания на прод.

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

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

devops/sre и без Go может это сделать, на чистой этой вашей жаве

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

первый квест в том, чтобы вообще собрать этот код и получить релизные артефакты для развертывания. Для примера, когда нам передали этот код для улучшения, мы (разработчики-программисты) в течение двух недель учились только собирать и запускать этот код - и по-моему, так и не научились.

Второй квест в том, чтобы обмазать релизные артефакты скриптами на энсибле, пайтоне и баше, и совместить это с ченжами в архитектуре приложения инфраструктуре. Третий - в написании толстенной инструкции для админов (админы обычно не хотят разбираться в скриптах, им нужно вордовский файл на триста страниц, в котором описываются команды, которые нужно выполнить в командной строке - иначе говоря, плейбуки, описанные «человеческим» языком). На выходе всех квестов получается готовая поставка для развертывания на прод.

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

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