Сегодня я хотел написать этот пост, но краткое вступление раздулось до огроменного ставшего в результате самодостаточным поста. Тут же я поделюсь серией подобных практик в одной узкой области - сборка и поставка приложения. А пост этот был написан с использование другой практики - make manual from chat log. Когда ты с коллегой в чате уже обсудили какой-то вопрос, ты настрочил много текста и теперь хочешь его как-то повторно использовать. Так что этот пост, как и многие другие - во многом вдохновлен обсуждением вопроса в чате, скопипащенный оттуда и немного отредактированный.
Итак погнали. Я ленив, а потому если команду в консоли bash/batch я ранаю второй раз за сегодня, тут же останавливаюсь и начинаю писать bash/batch скрипт: bash для linux, batch для windows. За последние пару лет эта практика меня сильно прокачала в этих сприктовых языках программирования. Если раньше мне приходилось гуглить как делается в OS так или иная операция или выполняется та или иная команда, то сейчас я гуглю особенности различных языковых конструкций: if/else/while/function/ect, как делаются те или иные expression и так далее. Этот язык программирования (вообще правильно command language) весьма специфический и более того их два диалекта - для windows и для linux. Почему диалекта, потому что очень многое слизано (как мне кажется) у windows с linux. Отличия все же приходится гуглить.
Раньше я писал скрипты для обоих OS. Но в последнее время склоняюсь в сторону linux, а для тех, кто работает под windows предлагаю для запуска моих bash скориптов использовать что-то типа cygwin или mingw. Очень в немногих местах приходится проверять OS и менять поведение скрипта в зависимости от OS. Но это куда лучше чем писать две версии скриптов, либо лишать windows пользователя инструмента автоматизации.
Идем дальше. Загнать тот скрипт, который ты обычно ранаешь в консоли в текстовый файл и назвать с расширение bat/sh это первый шаг, но этого недостаточно. Часто новички в DevOps часто используют команду cd для того, чтобы направиться в определенную папку, и там уже выполняют команду. Я же пришел к тому, что каждую команду стоит выполнять в абсолюте.
Все что выполняется относительно, всегда потом дает повод поиграться с ним в самый неподходящий момент.
cd ./some/place/in/project
ls -la
cd ../../..
cat file.txt
В суппорте такой подход требует от меня всегда помнить "где я?". То есть для каждой строчки надо помнить 2 вещи - ЧТО делаем, ГДЕ делаем. А если ты юзаешь всегда только абсолютный путь, тогда все чисто.
ls -la /srv/app/some/place/in/project
cat /srv/app/some/file.txt
Более того, рекомендовано использовать такие команды даже когда ты работаешь в консоли руками. Если говорить про linux то там в папке твоего юзера есть ~/bash_history файл и в нем все команды когда-либо выполняемые тобой на этой машине. Очень информативно видеть там самодостаточные команды, выполнив которые из любого места системы будет один и тот же эффект.
Но как быть с дублированием? Допустим я не хочу постоянно вбивать /srv/app/some
ls -la /srv/app/some/place/in/project
cat /srv/app/some/file.txt
В скрипте (bash) сделать так
root=$(pwd)
ls -la $root/place/in/project
cat $root/file.txt
В batch вот так
set root=%cd%
dir %root%\place\in\project
type %root%\file.txt
Следующим шагом я бы улучшил информирование в консоли (bash).
BLUE=94
GRAY=89
YELLOW=93
color() {
message=$1
[[ "$2" == "" ]] && color=$YELLOW || color=$2
echo "[${color}m${message}[0m"
}
eval_echo() {
command=$1
[[ "$2" == "" ]] && color=$BLUE || color=$2
color "${command}" $color
echo
eval $command
}eval_echo "set root=%cd%"
eval_echo "dir %root%\place\in\project"
eval_echo "type %root%\file.txt"echo
color "Press Enter to continue"
read
И тогда вывод будет намного более приятным. Перед выполнением лога работы каждой команды будет напечатана другим цветом сама команда. А в самом конце скрипта подождем нажатие Enter с тем, чтобы убедиться что оператор все осознал и возражений не имеет.
Согласись так нагляднее, чем видеть все то же самое только без цветных строчек.
Удобство этого подхода в том, что вместо переменных типа $root будет вставлено реальное значение и на экране напечатается информативная команда, именно та, что будет реально вызвана.
А если не хочется копипастить из скрипта много кода, то напомню, что самый минималистичный вариант eval_echo это
eval_echo() {
echo "[94m$1[0m"
eval $1
}
Обрати внимание, что в этом коде есть ESC символ.
Благодаря этому символу в linux консоли можно рисовать цветом. Под bacth есть подобный подход.
Все это сильно позволяет ускориться во время выполнения обычных рутинных действий: залить ветку на github со всеми subrepo, pull всех subrepo, автоматическая генерация каких-то ресурсов, создание snapshot для всех артефактов, создание запускного jar для каждого компонента с автоматически сгенерированными скриптами запуска, запуск сервера в целях отладки в определенной конфигурации, дамп базы и так далее. Все это делалось вручную раньше, а сейчас на это не тратится время. Время (сильно меньше) тратится на поддержание скриптов. Это экономически выгодно, иначе небыло бы DevOps с CI/CD и мы собирали war вручную или с Ant, заливали бы его в папку Tomcat на сервере, разбирались бы с конфликтом jar, как делали это 10 лет назад. Деплой бы занимал не 1 клик и 10 минут, а 1 час и много ручной работы.
Сообщения
