Ответы пользователя по тегу Непрерывная интеграция
  • Docker - архитектурные вопросы о деплое и не тольно?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) nginx-proxy
    2) копируйте исходники в образ (в dockerfile), собирайте либо локально либо на CI-сервере эти образы и пушьте их в docker/distribution (либо платный docker-hub либо разверните свой, это с докером делается за минут 10).
    3) Прямо в контейнере с PHP. Либо заведите отдельный контейнер для php-cli и зачедите отдельный контейнер для исходников, и через volumes_from расшарьте между ними. Вариант с cron на хосте тоже достоен существования, но это не ок в большинстве случаев.
    4) обновлять базовый образ. А там уж как организуетесь.
    5) Можно, смотрим пункт 2.
    6) Вообще тут можно схитрить. Вы можете же хранить зависимости прямо в репозитории, в смысле коммитить вендоры. Но вы этого не делаете. На момент когда запускается docker build ваших образов, все зависимости уже должны поставиться. И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.
    7) как мы выяснили в пункте 6 - композера на проде быть не должно. вообще как, вы оттещенный образ со стэйджинга должны просто "мувать" на продакшен. В этом плане риски при релизе минимальны.
    8) тут опять же по разному. Мне удобнее прямо из контейнера коннектиться например в sentry или graylog и скидывать туда логи. Ну или мы должны пихать логи в stdout/stderr контейнера и далее агрегировать их снаружи, тут так же есть куча вариантов.
    9) все это отдельные контейнеры, все это вместе связывается башем и docker-compose. Все это разварачивается либо через docker-machine и CI либо просто через CI. Docker-machine будет "удобным" только с версии 0.7 или 0.8.
    Ответ написан
    2 комментария
  • Доставка проекта на продакшен, какие инструменты для деплоя?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    docker

    собираем на CI-ке контейнер, прогоняем на нем тесты (вы же сказали что проект большой, большой проект без тестов - боль), если все хорошо - пушим в docker hub или в свой локальный docker distribution, после чего можно на серваке сделать просто docker-compose pull && docker-compose up -d и радоваться.
    Ответ написан
  • Что такое build agent в CI?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    да, это сервер на котором происходит сборка. У меня скажем есть один мастер сервер где установлен Jenkins, и 3 агента (один на маке для сборки под iOS и два на linux для андроида и вэба).

    выполняют build на клиенте

    Лучше отдельный сервак. CI-ка всегда должна иметь доступ к своим слэйвам. Хотя думаю можно извратиться.
    Ответ написан
    1 комментарий
  • Как при помощи CI вы тестируете сайты?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Очень любопытный вопрос. Самому интересно как люди делают дела.

    Нужно ли перед запуском перенастраивать через ansible среду выполнения?


    Нужно или нет - зависит от того менялось ли окружение. Я обычно просто запускаю vagrant up --provision. Провиженинг занимает секунд 20-30 (если ничего не поменялось, всему виной apt-get update, но с ansible 2 эти 10 секунд которые тратятся на update индекса пакетов исчезнет, хотя похоже что я раньше на docker перейду полностью).

    И как настроить систему так, чтобы возможна было проверка нескольких коммитов одновременно.

    Я проверяю только последний коммит для ветки. То есть по сути это решает проблему с несколькими коммитами (проверяем мы только то что изменилось с последнего запуска CI-ки).

    Следовательно нужно под каждый инстанс использовать свою виртуалку, внутри которой есть GUI

    не GUI а X-ы, это чуть другое. Опять же можно извратиться и поставить сам силениум на хост, а управлять им из вагранта... но это сложно как по мне.

    Что до инстансов - я использую только один инстанс на джобу.

    Их динамически создавать по образу, или сразу развернуть количество виртуалок по числу агентов?

    Ну как бы... они динамически и будут создаваться если у тебя джоба будет постоянно прыгать с агента на агент. Обычно они не прыгают так часто. vagrant up --provision решает все проблемы в плане развертывания виртуалки. В этом плане перспектива миграции на Docker мне очень сильно нравится.

    Куда более интересный вопрос - управление прекондишеном для UI тестов, то есть это либо загрузка фикстур под сюиту, либо вызов консольных команд либо еще как... С Behat скажем я просто для установки прекондишена использую сервисный слой приложения. А если вдруг захочу тестить UI мобилки, то на этот случай я написал простенький раннер для behat-а который позволяет запускать отдельные степы, тем самым я могу реюзать тесты для Behat в тестах для калабаша например (для установки прекондишена тестов).

    Выбор CI: Jenkins или TeamCity.

    Разница не столь велика на самом деле. Под Jenkins больше плагинов и прикольных штук но это стремная штука. Сам я пока сижу на дженкинсе.
    Ответ написан
    4 комментария
  • Continuous Deploy. Не только вперед по истории коммитов git, но и экстренно назад?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Docker + Ansible. При деплое поднимаете контейнер с новой версией приложения (старая версия в скоем контейнере и пока работает), накатываете миграции (условие - миграции одной версии не должны вести к неработоспособности старой, иначе у вас проблемы с проектированием базы), подменяете текущий контейнер на новый и тушите его. Если вдруг что-то пошло не так, запускаете скрипт который проведет операцию в обратном направлении.

    Если Docker смущает своей молодостью, есть вариант с оформлением приложения в виде DEB-пакета.

    А еще есть Capistrano.

    p.s. Довольно интересная тема, но на большинстве проектов, с которыми довелось сталкиваться или общаться с разработчиками оных, популярна стратегия "фиксить АСАП!" (за редкими исключениями, причем даже если минута простоя стоит тысячи долларов). Обычно это связано с тем что такие ситуации не случались ибо все предварительно обкатывается на стэйджинге с копией реальных данных.
    Ответ написан
    2 комментария
  • Как организовать процесс разработки продукта на C++, используя GIT?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    то что вы описывается называется feature-branch.
    ваши фича-брэнчи должны всегда быть синхронизированны с мастером. У всех разработчиков должна быть актуальная версия кода, с которым они работают. В этом смысле подход с feature-branch, особенно когда речь идет о больших изменениях, может сильно рассинхронизировать код между разработчиками.

    Мне больше нравится подход с Feature Toggle, так как он более соответствует философии git.
    Ответ написан
    Комментировать