Работа в команде, с функциями запросов на вытягивание с проверкой кода и некоторой автоматизацией с CI для предотвращения слияния неудачных тестов или кода не-linted в ваш мастер. филиал. Звучит знакомо?
Но почему мы должны останавливаться на тестах или линтинге? То, что я собираюсь объяснить здесь, относится к конвейерам Bitbucket, главным образом потому, что это то, что я использовал в последнее время. Но я почти уверен, что идея и основные концепции, лежащие в ее основе, применимы и к другим КИ.
Наш вариант использования
Мы работаем над мультиплатформенной разработкой с помощью Nativescript и Angular. Если вы когда-либо работали с мобильными устройствами, вы знаете, что управление версиями — это серьезно, поэтому мы хотели убедиться, что не пропускаем версии при добавлении новых функций в наше приложение.
Мы используем семантическое управление версиями, поэтому автоматизация изменения версии не имеет смысла, поскольку вы не можете автоматически решить, хотите ли вы изменить основную, второстепенную или исправленную версию. Мы пришли к выводу, что конкретный номер для следующей версии должен быть определен разработчиком, представляющим функцию в своем запросе на включение.
Наше решение
Как вы, возможно, уже догадались, наше решение состоит в том, чтобы добавить проверку конвейеров репозитория Bitbucket, который представляет собой интегрированный CI для Bitbucket, аналогичный CircleCI или TravisCI, если вы когда-либо работали с ними на Github.
Установка
Наш скрипт проверит, что входящая версия — версия, установленная разработчиком в его функциональной ветке — является действительной, т. е. превосходит текущую.
Чтобы быть уверенным в этом, нам нужны две ссылки, текущая версия и входящая версия. Мы решили, что входящая версия должна быть той, которая определена в нашем package.json в корне нашего исходного кода, и это и только эта ссылка на код версии — это то, что разработчик должен обновить.
Нам также нужна была ссылка на версию для сравнения при запуске нашего скрипта, и мы решили поместить ее в файл version-lock.json также в корне нашего приложения. Этот файл будет содержать только текущую версию, например:
{ "version": "1.0.0" }
Выполнение
Небольшое примечание: ключ к тому, чтобы заставить эту работу работать, заключается в том, что мы снова воспользуемся преимуществами конвейеров после слияния функциональной ветки, чтобы запустить скрипт, который обновит это число текущим в package.json, тем самым обеспечив завершение цикла. и несоответствующие запросы на вытягивание, поступающие позже, будут надежно заблокированы.
Переходя к забавным вещам, первое, что нужно сделать, это определить скрипт в нашем package.json и создать файл js, содержащий логику:
Я не могу вникать в реализацию скрипта, но важно знать, что конвейер выйдет из строя, если команда завершается с ненулевым кодом выхода, например throw().
После того, как сценарий был создан и определен в нашем package.json, мы могли двигаться дальше и сообщать конвейерам, когда его запускать:
Как вы можете видеть, мы разместили его после наших тестов, npm run version-check запустит скрипт, который мы создали ранее, и, если разработчик забудет изменить версию, сборка завершится следующим образом:
Это вынуждает разработчика зафиксировать новое изменение с помощью бампа, и таким образом мы никогда не забываем объединить новую функцию, не обновляя версию. Та-да!
Последние замечания
Я как-то раньше дразнил: после слияния должен запускаться новый скрипт на пайплайнах и обновлять версию на version-lock.js. Но это включает в себя внесение изменений в код, их коммит и отправку через ssh из пайпов. Это, конечно, чертовски весело, но для объяснения потребуется еще несколько строк, поэтому я собираюсь оставить этот пост как есть, мы углубимся в это в следующей части.
Спасибо за чтение, если вы дочитали до этого момента, и, пожалуйста, если вам есть что сказать, просто напишите что-нибудь в комментариях или передайте привет мне в твиттере.
