Комментарии 28
scp file ci-server.com:/home/user/ci-trigger
Что может быть сложнее, чем подключить репу, развернуть gitlab (обновлять так же), на деплой сервере развернуть gitlab-runner и прописать конфиги в репах?
Окей. Билд упал, как об этом узнать? Как узнать что упало? Смотреть ручками файл лога? А какие-то нибудь junit и прочее? А конфигруация разных параметров, инкремент номера сборки, а хочется две+ машины для сборщиков? И опять же, "не требующий развертывания большего", но требующий настройки почты, например.
А где хранить пароли к бд? А если хочется посмотреть как меняется динамика каких-то показателей, например растет или уменьшается количество warning? И, заодно зафейлить билд, если оно выросло?
А если нужно пересобрать, что делать, фейковый пустой коммит? А как указать параметры окружения куда конкретно деплоить в данный момент? Например, на stage, rc или прод?
Окей. Билд упал, как об этом узнать?
Вся соль кроется тут:
...
ci_archive &&\
ci_report || ci_error
Либо все функции вернут 0 и выполнится ci_report, уведомляя юзера об успешном билде, либо выполнится ci_error, уведомляя того же юзера об ошибке билда.
А какие-то нибудь junit и прочее?
Не понял вопроса, что именно не так с junit? Если речь о том, как его запустить и обработать выхлоп, то через консоль с выводом в stdout.
А конфигруация разных параметров, инкремент номера сборки, а хочется две+ машины для сборщиков?
Так это чистый Bash, там можно все что вы сможете придумать. Про несколько машин-сборщиков тоже не совсем понял, в чем вы видите проблему?
А где хранить пароли к бд?
Ну это уже вам решать, можно просто создать файлик по типу passwd с доступом только от имени юзера CI-trigger.
А если хочется посмотреть как меняется динамика каких-то показателей, например растет или уменьшается количество warning? И, заодно зафейлить билд, если оно выросло?
Мониторинг это уже немного из другой оперы, данное решения его не подразумевает.
Понятно что все можно сделать на чистом bash, вопрос в удобстве и количеству телодвижений. Так же как и стандартный вывод junit несколько не удобен для чтения в явном виде, особенно без привязки к коду.
Про несколько машин-сборщиков тоже не совсем понял, в чем вы видите проблему?
У вас есть две машины со сборщиками (вашим CI), вы делаете пуш, какая из этих машин заберет эту задачу? Обе сразу?
Так это чистый Bash, там можно все что вы сможете придумать
Как мне в вашем сборщике выкатить на прод/следующий-стейдж/qa — в общем, один и тот же коммист на разные окружения. Если для прода еще можно придумать, что на прод едут только ветки master, например, то ручной редеплой на разные окружения вызывает вопросы.
Я надеюсь, для таких задач вы не будете поднимать GitLab или Jenkins, а просто закините на сервер (расбери) bash-скрипт и пропишите хук для git. Вот это примерно то, где я советую юзать данное решение. Если вы хотите чего то большего, то естественно вам нужно что-то серьезнее.
У вас есть две машины со сборщиками (вашим CI), вы делаете пуш, какая из этих машин заберет эту задачу? Обе сразу?
Зависит от того, как вы сконфигурируете хук и вызов триггера.
Как мне в вашем сборщике выкатить на прод/следующий-стейдж/qa — в общем, один и тот же коммист на разные окружения
Я бы предложил для тестирования в различных окружениях использовать Docker-контейнеры. Повторюсь — решение очень упрощенное, это не конкурент какого нибудь Travis.
Не проще ли было бы сделать на устройстве просто удаленный репозиторий, на который пушим, а в удаленном репозитории хук на деплой?
Не проще ли было бы сделать на устройстве просто удаленный репозиторий, на который пушим, а в удаленном репозитории хук на деплой?
Так это оно и есть ) Я писал чуть выше об этом:
Вы не хотите заниматься деплоем в этом проекте, а просто пушить правки в ваш репозиторий (на той же расбери или в github) и чтоб он релизился автоматически
Одна из реализацией: вы размещаете репозиторий на CI-сервере, вы прописываете в hook вызов CI-trigger, вы добавляете в конфигурацию триггера git pull и все что нужно для развертывания.
Если же у вас исходники хотятся на той же машине, что и CI-сервер, то вы можете добавить hook в git, который будет вызывать триггер CI как то так: /home/user/prj/trigger — и будет вам счастье.
Я надеюсь, для таких задач вы не будете использовать свой, мягко говоря, костыль. В случае с расбери лучше замарочаться (это не долго) и пакетики собирать и доверить автоматически обновлять обновлялке пакетов.
И вы описали кейс CD, а не CI, что достаточно другая категория продуктов и решений тоже хватает. Гораздо более простых, причем встроенных в практически любой сборщик типа мавена, фабрики и подобного.
В случае с расбери лучше замарочаться (это не долго) и пакетики собирать и доверить автоматически обновлять обновлялке пакетов
Для просмотра погоды собирать пакеты под текущую ОСь? Серьезно? ) Я вас понял, спасибо за совет ))
И вы описали кейс CD, а не CI, что достаточно другая категория продуктов и решений тоже хватает.
Если я добавлю тест перед деплоем и отсылку мне результатов на почту, то это дотянет до CI?
В вашем случае тоже используется bash не по назначению, так как можно легко использовать любой готовый CI.
Отслеживает изменения в файлах и выполняет последовательность действий
Проблема в том, что частенько в CI отслеживаются не изменения в файлах, а изменения в версии или коммиты.
В вашем случае тоже используется bash не по назначению
Но ведь у баша назначение — объединять готовые тулзы для выполнения задачи, что я и сделал )
Хоть bash и есть универсальное средство, но в этой задаче он не очень подходит, так как нужно отслеживать изменения файлов и выполнять шаг только тот который необходим. А отслеживать изменения файлов прекрасно умеет make.
CI: непрерывная интеграция за 5 минут