Приложения Angular с легкостью обновляются с помощью Angular CLI. Обновление до основных релизов, как правило, происходит в течение недели после выпуска без возникновения проблем, начиная с Angular 4.
Мы разработали 5 шагов в CI pipeline. В данном примере используется Jenkins, но можно выбрать и другой CI pipeline.
5 шагов включают:
После очистки рабочего пространства необходимо проверить (checkout
) ветку master
и создать новую отдельную ветку. Поскольку мы используем что-то похожее на git-flow
и semantic commit messages
, то сгенерированные ветки выглядят следующим образом: chore-ngupdate/autoupdater-2019-05-21
.
Angular CLI обладает встроенной функцией обновления. Запуска ng update --all
будет достаточно для большинства решений. В случаях запуска приватного репозитория, такого как Nexus, при использовании флага --all
возникают некоторые проблемы. Однако можно выполнить сценарий с использованием команд grep
и awk
для получения результатов, необходимых для ручного ввода команд ng update @angular/core rxjs ...
:
ng update --registry https://path/to/your/registry 2>&1 | tee update-result.txt
if [[ $(head -n 1 update-result.txt) = *"We analyzed your package.json, there are some packages to update:"* ]];
then
grep -E "^\s+[@/a-zA-Z0-9]+\s+.+->" update-result.txt | awk '{print $1}' | tee to-update.txt
UPDATE_CMD=""
for pkg in $(cat to-update.txt);
do
UPDATE_CMD="${UPDATE_CMD} $pkg"
done
ng update $UPDATE_CMD
fi
На этом этапе необходимо определить наличие обновлений (No outdated dependencies!
), совместимость обновления с автоматическим обновлением или успешное выполнение автоматического обновления, а также наличие изменений в файлах в файловой системе. В зависимости от вышеприведенного результата мы возвращаем ненулевое значение (return non-zero
) и отправляем сообщение на коммуникационную платформу, чтобы предупредить разработчика.
Когда обновление прошло успешно, а в файловой системе произошли изменения, можно запустить по умолчанию pipeline, который содержит ng test
и ng e2e
. Тем не менее среда автоматически выполняет задания CI по pull requests
, поэтому мы просто создаем pull request
, а CI принимает его оттуда.
Это означает, что нужно зафиксировать (commit
) новую ветку и отправить (push
) ветку в репозиторий. Чтобы это работало, возможно, потребуется предоставить разрешение SSH key
CI на создание и передачу новых веток.
Затем используем предоставляемые API от Git management platform
, такие как Github или Gitlab, для создания нового Pull Request
. Этот процесс заключается в отправке HTTP POST
на URL с необходимой payload
, содержащей branch name
, target branch
и title
, отражающие изменения.
После этого CI автоматически создает и выполняет pull request
, чтобы проверить, не нарушают ли изменения pipeline.
При желании можно включить коммуникационную платформу. С помощью простого вызова Webhook
в форме HTTP POST
для Slack (или подобные альтернативы) можно уведомить канал о новом (автоматическом) pull request или неудачной попытке. Мы также отправили сообщение при запуске обновления, но изменения зависимостей не были обнаружены.
В нашем случае, это легко интегрируется с проделанными шагами, где конечный результат содержит ссылку на новый pull request
. Неудачная попытка с несовместимыми изменениями или успех без каких-либо изменений приводят к появлению различных сообщений. Благодаря этому разработчики знают о любых изменениях за пределами разработки.
CI позволяет автоматически планировать сборки, а такие решения, как Jenkins и GitLab, предлагают их из коробки.
Если CI не поддерживает этот метод, есть множество других способов достичь подобного результата, например, с помощью cronjob
, запускающего восстановление на autoupdater
pipeline.
Мы автоматизировали эти шаги по двум причинам:
Мы настоятельно рекомендуем изучить эти возможности для вашего собственного проекта, чтобы сэкономить драгоценное время!
Перевод статьи Bjorn Schijff: How we automated our Angular updates
Комментарии