CI/CD и способы деплоя
Надежный деплой строится на атомарном переключении релизов через симлинки и версионировании кода в Git, исключая небезопасные правки по FTP. Неверсионируемые данные (/upload, кеш, .settings_extra.php) подключаются как общие постоянные директории, а пайплайн завершается накатом миграций и перезапуском PHP-FPM для сброса кеша байткода.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
FTP/SFTP (ручной)
-
2
Git + SSH
-
3
CI/CD (GitLab CI, GitHub Actions)
-
4
Docker
Материалы
Официальная документация
-
Консольные команды Новая дока
Проверь себя
После деплоя через симлинк релизов сайт отдаёт старый код, хотя файлы новые. Почему?
OPcache закешировал байткод по старому пути и не проверяет время файлов. После переключения симлинка нужен reload php-fpm; это должно быть шагом пайплайна, а не ручным действием.
На следующий день после деплоя перестали загружаться картинки в админке. Что сделал деплой?
Файлы выложены от root, а PHP в BitrixEnv работает под bitrix и не может писать рядом с ними. Деплой должен выполняться под пользователем bitrix или заканчиваться chown.
rsync --delete снёс .settings_extra.php, и сайт лёг. Как строить раскладку, чтобы этого не случалось?
Всё, что не в Git — upload, cache, html_pages, .settings_extra.php — живёт в общей папке вне релизов и подключается симлинками. rsync ходит только в папку релиза.
Заказчик хочет прод в Docker. Что его ждёт?
Обновления из админки и /upload меняют файлы внутри контейнера, поэтому /bitrix и /upload выносятся в тома; агенты, push-сервер и композитный nginx — отдельные контейнеры и конфиги. Окупается при наличии devops, иначе BitrixEnv проще.
Не сходится?
Спросите ассистента BXMax: он знает документацию и материалы сайта по этой теме.
Знаете материал лучше?
Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить