Обновление пакетов при CI/CD
Время от времени в проекте желательно обновлять пакеты через Composer и Yarn. Иногда это происходит без ошибок. К счастью, у нас в этот раз оказалось не так :)
Это хороший повод рассмотреть семантическое версионирование и произвести минорные и мажорные обновления зависимостей. Покажем, что делать, если появилось много ошибок. И найдём способ непрерывно обновлять зависимости при следовании философии CI/CD прямо в master так, чтобы это не ломало код, не стопорило разработку проекта и не порождало веток с устаревающим кодом.
- 00:02:39 Удаление символической ссылки
- 00:03:54 Удаление Docker Compose
- 00:05:36 Команда api-check
- 00:07:00 Просмотр списка новых пакетов
- 00:08:24 Семантическое версионирование
- 00:14:31 Пробный запуск
- 00:15:46 Способы работы с ошибками
- 00:17:32 Страх обновлений
- 00:18:04 Проблема подхода с feature-branches
- 00:20:13 Следование принципам CI и CD
- 00:21:47 Постепенный подход
- 00:22:33 Пакеты с зависимостями
- 00:24:38 Исправление ErrorHandler
- 00:32:14 Композиция или наследование
- 00:34:16 План обновления Psalm
- 00:36:06 Работа с группами компонентов
- 00:37:42 Обновление Psalm
- 00:38:20 Если ошибок много
- 00:41:01 Исправление типа
- 00:45:03 Обновление PHPUnit
- 00:47:28 Исправление аннотации covers
- 00:55:00 Пакеты UUID и линтера
- 00:56:16 Поиск помех обновлению
- 00:59:20 Общее обновление
- 01:00:26 Переход на Doctrine Migrations 3.0
- 01:08:05 Обновление фронтенда
- 01:09:27 Конфликт ESLint
- 01:10:58 Testing Library
- 01:11:32 Обновление Cucumber
Следующие эпизоды продолжим после скринкастов о React.
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо, высший класс, (как всегда).
Спасибо!
Спасибо, а будет ли про подключение внешних хранилищ типа Амазона и репликацию между распреденными базами данных?
Да, хотелось бы :)
Хранилища будут для загрузки фотографий с эмуляцией для девелоперского окружения.
ну отлично, спасибо
Есть вопрос все же, к примеру поменял кто то одну строчку в стиле, как ее быстро доставить на прод, минуя всю цепочку?
Как делаются быстрые изменения и как получить доступ к файловой системе запущенного контейнера?
Никак. Цепочка как раз и строится для того, чтобы ничто не поступило в прод без тестов в обход неё.
Иначе любое неосторожное ручное действие в проде вроде неверно поставленной запятой или незакрытой скобки в конфиге мгновенно сломает весь сайт. Ещё стоит учесть, что на проде используются минимизированные css и js файлы, а не исходные.
Работу с PHP в Docker воспринимайте теперь как работу с любым компилируемым языком. Там исходники есть только в репозитории и у вас, а для прода нужно скомпилировать всё в один файл и закинуть на сервер.
Для этого в деве есть тесты, после их прогона, если изменение незначительно, таких проблем быть не должно. Кстати есть ли линтеры для Makefile? Там лишний пробел в лево в право, расстрел сразу. Еще раз хочу поблагодарить, за прекрасный курс, кучу проблем решить помогло, ты настоящий гений.
Тесты в деве не проверяют контейнеры прода.
А так если нужны эксперименты на сервере в полуреальном времени без тестов, то сделайте отдельную ветку вроде drafts с отдельным сервером и в pipeline для неё через
branch != draftотключите все шаги кроме build и deploy-draft.Но как предложил ниже, проще показать заказчику свой экран, чем давать ломать продакшен ради ведения разработки по-живому.
Если стиль кнопки поменяется в проде не мгновенно, а через три минуты, то это мало кого расстроит.
Если с ростом проекта возникает неудобство, что цепочка становится слишком медленная, то либо повышают мощность сборочного сервера, либо оптимизируют запуск, либо делят проект на части.
Например, с коммитом из прошлой успешной сборки по
git diff ${env.GIT_PREVIOUS_SUCCESSFUL_COMMIT} apiможно понять, изменились ли файлы в папке api. И если не изменились, то сделать пропуск шагов. Тогда при изменении стилей фронтенда не будут запускаться линтеры, анализаторы и тесты api.Помимо этого при желании можно будет вынести фронтенд в отдельный репозиторий или разбить api на более мелкие микросервисы, живущие в отдельных репозиториях. Но это сложнее.
Это не всегда так, тут больше к моему вопросу в другой ветке, например заказчик смотри продукт и говорит все круто, но в этом поле не тот валидатор, я говорю, ок, жди пару минут, вношу изменения и запускаю процесс, его сессия отлетает со всеми пробами или вдруг оказывается, что кончилось место га диске или типа того, он говорит, ок, я улетаю, через месяц встретимся, а я сегодня планировал сдать.
Все же считаю, что должна быть возможность оперативного вмешательства, мы мельком коснулись DFS, а что если бы файлы проекта лежали на ней с доступом через SSH?
Это ведь могло бы решить подобные проблемы, строгость конечно, хорошо, но в реальной жизни бывают всякие ситуации, гибкость не помешает, мало что там случится.
Понятно, что такой доступ всем не дается.
Если это нужно только для разработки, а не посетителям сайта, то незачем это делать в проде.
Тогда сразу после просмотра проще показать ему свой экран через Zoom или дать покликать через TeamViewer.
Кстати да, тоже вариант, спасибо.
Дмитрий подскажите пожалуйста как решить проблему с psalm и doctrine. Я использую метод orX в который передаю несколько параметров $q->where($q->expr()->orX('u.type = ?1', 'u.role = ?2')); При проверке репозитория psalm получаю следующую ошибку Too many arguments for method Doctrine\ORM\Query\Expr::orx - saw 5. Заранее спасибо.
Либо самому подавить ошибку аннотацией в своём коде или в конфигурации
<issueHandlers>для метода orX класса ExpressionBuilder, либо глобально подключить doctrine-psalm-plugin.Теперь на сервере при каждом деплое будет создаваться новая папка site_{$BUILD_NUMBER}. А старые мы не удаляем...
В этой папке хранится только файл
docker-compose.ymlи, возможно, файлы с ключами.Если размер папки 10КБ, то при 10 деплоях в день за год три тысячи папок займут всего 30МБ.
Или войти через: