При разработке различных приложений в одной и той же области вы, скорее всего, столкнетесь с необходимостью использования тех же функций, которые уже были реализованы в другом приложении. Однако в проекте с большим количеством различных приложений, репозиториев кода, микросервисов и разработчиков ни в коем случае нельзя использовать гибкую и эффективную стратегию совместного использования кода. В Fortum Oslo Varme (где я работаю техническим руководителем) у нас есть политика совместного использования кода, согласно которой всегда создаются повторно используемые пакеты кода для функций, которые необходимы более чем одному компоненту. Таким образом, легко контролировать расположение кода, улучшать удобство сопровождения, сокращать количество ошибок и время, затрачиваемое на кодирование, а также упрощать внедрение новых функций и исправлений во все компоненты, использующие одну и ту же функциональность. У нас есть собственные частные реестры кода для наших пакетов кода .NET Core и Angular, а это означает, что у нас есть один реестр NuGet и один реестр NPM.
Давайте начнем с обзора нашей платформы совместного использования кода на рисунке ниже:
Процесс разработки и выпуска
Все код-пакеты размещаются в собственных репозиториях кода (если несколько пакетов тесно связаны, их можно разместить в одном репозитории), а во время разработки все пакеты имеют суффикс «бета» в номере версии. Бета-суффикс существует, потому что большинство систем управления пакетами кода поддерживают ссылки на пакеты кода с подстановочными знаками, что означает, что вы можете, например, объявить свою зависимость от пакета кода как «1.0. *», и вы получите новейший бета-пакет для версии «1.0.0» каждый раз, когда вы восстанавливаете свои зависимости. Бета-суффикс нужен для того, чтобы гарантировать отсутствие критических изменений в наших пакетах кода во время разработки, поскольку это затем будет обнаружено в наших ночных сборках непрерывной интеграции, где все компоненты приложения восстанавливаются, собираются и тестируются. С бета-суффиксом мы всегда следим за тем, чтобы новейшие пакеты кодов были действительными и не нарушали существующую функциональность.
Когда новая функциональность объединяется с нашей веткой «разработка» в репозитории GIT для пакетов кода, мы автоматизировали сборку и публикацию пакетов кода в наших реестрах кода по расписанию, а это означает, что новые бета-пакеты всегда публикуются сразу после новая функция была объединена в ветку «Разработка». Для окончательных выпусков мы всегда делаем ручную публикацию пакета нашего нового тега выпуска в репозитории в наши реестры кода.
Когда приложение готово к выпуску в производство, мы всегда делаем окончательные выпуски пакетов кода, от которых зависит это приложение, и обновляем зависимости этих пакетов до их окончательных версий выпуска, например. «1.0.0» вместо предыдущей бета-версии «1.0.*».
Соглашения об именах
Все имена наших пакетов кода начинаются с нашего доменного имени, за которым следует приложение, которому принадлежит пакет кода, и, наконец, имя функциональности в пакете. Примером такого пакета является «Heating.CustomerPortal.Domain», который представляет собой повторно используемую функциональность для выполнения операций на нашем сервисном уровне, взаимодействующем с базой данных нашего клиентского портала. У нас также есть общие пакеты кода, которые применимы к нашим различным приложениям, например, «Heating.Shared.Utilities», который является нашей общей библиотекой утилит.
В следующем сообщении в блоге я приведу конкретный пример того, как вы можете быстро создавать и публиковать свои собственные пакеты NPM.
