Comments 28
GitLab?
А еще Jenkins, Trevis, TeamCity, Drone и Bamboo ) Я думал этот вопрос я закрыл еще в начале статьи. Ну если вам интересно, я повторюсь — у меня было свободное время и желание найти (или написать, если потребуется) CI, не требующей развертывания большего, чем
scp file ci-server.com:/home/user/ci-triggerИ ручное управление хуками, разграничение прав разрабов на серверах…
Что может быть сложнее, чем подключить репу, развернуть gitlab (обновлять так же), на деплой сервере развернуть gitlab-runner и прописать конфиги в репах?
Что может быть сложнее, чем подключить репу, развернуть 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, например, то ручной редеплой на разные окружения вызывает вопросы.
Возможно вы не совсем поняли цели юзания данного решения. Представьте что у вас есть Raspberry Pi, который 4 раза в час опрашивает гисметео и показывает вам на небольшом экранчике прогноз погоды. Вы не хотите заниматься деплоем в этом проекте, а просто пушить правки в ваш репозиторий (на той же расбери или в github) и чтоб он релизился автоматически, или сообщал вам об ошибке.
Я надеюсь, для таких задач вы не будете поднимать GitLab или Jenkins, а просто закините на сервер (расбери) bash-скрипт и пропишите хук для git. Вот это примерно то, где я советую юзать данное решение. Если вы хотите чего то большего, то естественно вам нужно что-то серьезнее.
Зависит от того, как вы сконфигурируете хук и вызов триггера.
Я бы предложил для тестирования в различных окружениях использовать Docker-контейнеры. Повторюсь — решение очень упрощенное, это не конкурент какого нибудь Travis.
Я надеюсь, для таких задач вы не будете поднимать GitLab или Jenkins, а просто закините на сервер (расбери) bash-скрипт и пропишите хук для git. Вот это примерно то, где я советую юзать данное решение. Если вы хотите чего то большего, то естественно вам нужно что-то серьезнее.
У вас есть две машины со сборщиками (вашим CI), вы делаете пуш, какая из этих машин заберет эту задачу? Обе сразу?
Зависит от того, как вы сконфигурируете хук и вызов триггера.
Как мне в вашем сборщике выкатить на прод/следующий-стейдж/qa — в общем, один и тот же коммист на разные окружения
Я бы предложил для тестирования в различных окружениях использовать Docker-контейнеры. Повторюсь — решение очень упрощенное, это не конкурент какого нибудь Travis.
Если вам надо чекать гисметео, то такой код один раз пишется и больше не трогается, пока работает. И такие вещи можно хоть руками закидывать один раз и забыть…
Сначала чекаем гисметео, потом понимает, что расбери может большее и пошло-поехало. Обычно так оно и бывает у программистов )
Т.е. увеличиваем количество репозиториев для деплоя и тем самым увеличиваем баш-скриптов деплоя или допиливаем текущие баш скрипты, чтобы можно было разграничивать деплои?
Не проще ли было бы сделать на устройстве просто удаленный репозиторий, на который пушим, а в удаленном репозитории хук на деплой?
Не проще ли было бы сделать на устройстве просто удаленный репозиторий, на который пушим, а в удаленном репозитории хук на деплой?
Не проще ли было бы сделать на устройстве просто удаленный репозиторий, на который пушим, а в удаленном репозитории хук на деплой?
Так это оно и есть ) Я писал чуть выше об этом:
Вы не хотите заниматься деплоем в этом проекте, а просто пушить правки в ваш репозиторий (на той же расбери или в github) и чтоб он релизился автоматически
Одна из реализацией: вы размещаете репозиторий на CI-сервере, вы прописываете в hook вызов CI-trigger, вы добавляете в конфигурацию триггера git pull и все что нужно для развертывания.
Что-то из статьи я не уловил это, и не понял, зачем тогда слушать порт…
Возможно вы просто прочитали статью по диагонали ) Про порт, это в том случае, если у вас исходники хостятся на каком нибудь github и вам нужно при пуше в него, интегрировать правки на своем сервере. В этом случае вы на CI-сервере слушаете порт, а github заставляете дергать этот порт при push commits.
Если же у вас исходники хотятся на той же машине, что и CI-сервер, то вы можете добавить hook в git, который будет вызывать триггер CI как то так: /home/user/prj/trigger — и будет вам счастье.
Если же у вас исходники хотятся на той же машине, что и CI-сервер, то вы можете добавить hook в git, который будет вызывать триггер CI как то так: /home/user/prj/trigger — и будет вам счастье.
Я надеюсь, для таких задач вы не будете использовать свой, мягко говоря, костыль. В случае с расбери лучше замарочаться (это не долго) и пакетики собирать и доверить автоматически обновлять обновлялке пакетов.
И вы описали кейс CD, а не CI, что достаточно другая категория продуктов и решений тоже хватает. Гораздо более простых, причем встроенных в практически любой сборщик типа мавена, фабрики и подобного.
В случае с расбери лучше замарочаться (это не долго) и пакетики собирать и доверить автоматически обновлять обновлялке пакетов
Для просмотра погоды собирать пакеты под текущую ОСь? Серьезно? ) Я вас понял, спасибо за совет ))
И вы описали кейс CD, а не CI, что достаточно другая категория продуктов и решений тоже хватает.
Если я добавлю тест перед деплоем и отсылку мне результатов на почту, то это дотянет до CI?
Для одиночных сборок хорошо подходит ansible. Вместо деления на функции там можно как вариант каждому шагу давать отдельный тег (или группу тегов) и вызывать потом только эти шаги.
Чем обычный Makefile хуже этого решения?
Сборка проекта и CI это немного разные вещи. Данное решение, на пример, может использовать Makefile в ci_build функции, для сборки исходных кодов проекта.
Makefile может не только собирать проект. С его помощью можно легко организовать зависимости между шагами которых нет в вашем скрипте. К примеру, не нужно запускать проект на сборку, если не изменились исходники. Тем более можно начать с любого шага и все необходимые шаги автоматом выполнятся.
Да, только с помощью Makefile нельзя собрать проект, протестировать его и уведомить по почте разработчика о результатах, при коммите изменений в систему контроля версий.
Да, ну? Из хука git запускается make, который из описания в Makefile проделывает эту работу: и протестирует, и по почте уведомит, и в Slack настучит, и еще кучу разных дел сделает, типа сборки дистрибутива программы. Не один раз встречал такое у разных команд и в разных проектах. Поэтому у меня возник вопрос о Makefile.
Я немного не о том. Make это сборщик проекта, конечно можно с его помощью сделать и больше, так как он позволяет вызывать внешние тулзы, но стоит ли использовать инструмент не по назначению?
По моему как раз он под это и заточен. Отслеживает изменения в файлах и выполняет последовательность действий.
В вашем случае тоже используется bash не по назначению, так как можно легко использовать любой готовый CI.
В вашем случае тоже используется bash не по назначению, так как можно легко использовать любой готовый CI.
Отслеживает изменения в файлах и выполняет последовательность действий
Проблема в том, что частенько в CI отслеживаются не изменения в файлах, а изменения в версии или коммиты.
В вашем случае тоже используется bash не по назначению
Но ведь у баша назначение — объединять готовые тулзы для выполнения задачи, что я и сделал )
Какая разница. Изменения версии или коммита не обходится без изменения файла на диске. Этим и занимается make.
Хоть bash и есть универсальное средство, но в этой задаче он не очень подходит, так как нужно отслеживать изменения файлов и выполнять шаг только тот который необходим. А отслеживать изменения файлов прекрасно умеет make.
Хоть bash и есть универсальное средство, но в этой задаче он не очень подходит, так как нужно отслеживать изменения файлов и выполнять шаг только тот который необходим. А отслеживать изменения файлов прекрасно умеет make.
Sign up to leave a comment.
CI: непрерывная интеграция за 5 минут