CI/CD и тесты

Привет! Желание написать этот пост назрело давно, а вот руки дошли только сейчас.

TLDR: Пишите тесты и используйте в работе Continuous Integration вместе с Continuous Delivery.

О чем пост

В целом к тому чтобы работу за меня выполняли компьютеры я тяготел всегда. Согласитесь, приятно же наблюдать за бегущими строчками в консоли сообщающими о том что компьютер в этот момент трудится над деплоем, тестированием или настройкой нового сервера? Приятно смотреть что настроенный один раз конфиг воспроизводится столько раз сколько это необходимо без каких-либо телодвижений со стороны человека.

Но из-за специфики работы (которую я выбрал сам) и собственной лени до тестов к CI/CD я шел долго. Да и сейчас иду.

Взгляд назад

Когда-то давно я работал над типовыми проектами на 1С-Битрикс. Тогда мы еще не использовали Git и вели разработки через панель управления CMS. Текстовый редактор использовался в режиме “покодил/скопипастил”. Ни о каких тестах и автоматическом деплое собственно разговоры не шли. В те времена это было нормой, да и типовые проекты в таком режиме в целом разрабатывать несложно. Но программистом себя в этот момент не ощущаешь.

Потом у нас появился крупный проект (стартап) и я предложил для его разработки взять только появившийся тогда Yii Framework, использовать git и вебхуки для деплоя на тестоый сервер. Поднимали в то время даже Jenkins который в итоге снесли за ненадобностью. Понятное дело что сделано все было простенько, но рабочие процессы в целом были настроены правильно. Коллега даже усиленно покрывал все unit-тестами, а я экспериментировал с Selenium.

Затем волею судеб я перешел на удаленную работу над интернет-магазином на одной известной CMS. По технологиям получается что вернулся почти что в битриксовые времена. Git-репозитории я конечно же настроил, но вот сервера были по прежнему “снежинки” настроенные вручную. Для локальной веб-разработки я тогда использовал Docker. Не совсем правильно, засунув весь LAMP в один контейнер. Но даже этот вариант был лучше установки серверного ПО прямо на десктопный Linux и лучше виртуальной машины в Vagrant. На этот момент из автоматизаций получается использовались свои Docker-контейнеры с разными версиями LAMP и самописные bash-скрипты для бэкапов.

Ну а потом началась эпоха компании Codabra agency.

Мы открыли компанию нацеленную на аутсорс и у нас была пара заказчиков поставляющих задачи. Тут не буду подробно расписывать. Скажу лишь что были задачи таких типов:

  • Проекты на различных технологиях с мелкими правками. Правки могли быть и на 20 минут и на 3 дня.
  • Доработка типовых Битрикс проектов
  • Небольшие кастомные проекты на Yii2 и Laravel.

В итоге получается что красиво можно было сделать только в третьем варианте. Тут не буду отмазываться. Можно было найти время и на тесты и на автодеплой, но делать мы это не стали. Если дойдут руки до подробного поста о Кодабре то там постараюсь раскрыть эту тему подробнее.

В начале 2019 года я начал работать фуллтайм на одного из заказчиков оставив все остальное своим сотрудникам. Там уже был крупный проект на Node.js и Python с правильным воркфлоу. Тесты я там писал, но деплоем на прод не занимался.

К этому времени docker-контейнер вида “все в одном” превратился в docker-compose проект с удобными настройками. Вручную настраивать сервера мне стало уже лень и потому на сервере я стал использовать тот же самый docker-compose что и для локальной разработки. В итоге вся настройка серверов свелась к созданию юзеров, прописыванию SSH-ключей и установке докера. Это вручную делать также стало лень и я настроил себе ansible-скрипт. Конфигурация серверов стала единообразной и повторяемой.

GitLab CI

Затем мне достался на доработку один проект на Yii2 в корне которого лежал сломанный .gitlab-ci.yml. Мне стало интересно, я почитал документацию и починил автодеплой.
С одной стороны это был небольшой оверкилл - на стороне гитлаба запускается Docker-контейнер с запускалкой на руби который подключается к удаленному серверу и запускает там процесс деплоя. Все это можно было заменить старым добрым вебхуком, но вариант с CI удобнее и информативнее.

В итоге войдя во вкус я настроил автодеплой еще для нескольких проектов на Yii2. Затем перенес несколько своих личных бложеков про автомобили на статик-генератор Hugo и разместил все на GitLab Pages. Деплоится все разумеется средствами GitLab.

GitHub Actions

К этому времени GitHub выкатил свой CI под названием Actions. Тут я настроил тестирование сборки своих docker-compose проектов и повесил на них красивые бейджики информирующие о статусе сборки.
Затем я перенастроил сборку этого блога. Блог собирается статик-генератором Hexo и долгие годы я пользовался его встроенной возможностью локальной генерации html-страничек и отправки их на сервер. Раньше я это делал rsync-ом, а уже потом стал коммитить html-ки в GitHub Pages используя для этого встроенный функционал Hexo.
Способ хороший, но есть неочевидный минус - нужно изначально использовать 2 репозитория. В один коммитить сам проект с markdown-файлами, а в другой сгенерированные html-ки. Иначе если случайно грохнуть бложек на компе то в наличии будет только статичная сгенерированная версия сайта.
Теперь используется также 2 репозитория, но коммичу вручную я только в один - туда где сам проект. Затем по коммиту в мастер запускается CI который собирает статичную версию сайта и сам коммитит ее в репозиторий для GitHub Pages.

Новая работа

Тут есть тесты и автодеплой, а также есть чему поучиться.

Выводы

Теперь я по возможности стараюсь не лениться и сразу писать код который нужно написать всего один раз и в дальнейшем он будет экономить огромное количество времени.
С тестами действительно сильно спокойнее за свой код, а вместо ручного деплоя лучше заварить себе чаю и попивать его глядя на то как компьютеры делают эту работу сами.

Вот такой капитанский пост получился. Но что самое интересное - я частенько встречал проекты компаний которые не то чтобы тесты и CI, но даже Git в работе не используют.