И немного моего взгляда на каждый фактор.
В 2010 году я впервые работал над созданием SaaS. Одна из моих первых и самых замечательных работ в качестве программиста. С тех пор это стало моим любимым типом проектов. Работая с проектами SaaS для клиентов и даже с другими проектами, которые не были точно SaaS, они были веб-приложениями, которые имеют много общего с SaaS.
Если вы вступаете в мир веб-программирования и не знаете подходящей методологии, вас ждет угощение.
1. База кода
Кодовая база должна быть уникальной, и из нее можно выполнять множество развертываний. Итак, здесь правило ясно: если у вас более одной кодовой базы, у вас не веб-приложение, а распределенная система, и каждый из этих репозиториев должен соответствовать 12 факторам.
На практике
Я вижу это в проектах Node.js как единый репозиторий для каждого веб-приложения в Git. В настоящее время много говорят о монорепозитории, где у нас есть несколько веб-приложений в одном репозитории. Тем не менее, то же правило применимо и к распределенным системам, потому что на практике вы должны развертывать каждый проект монорепозитория независимо. Таким образом, это отдельные веб-приложения.
2. Зависимости
Этот фактор говорит о том, что все зависимости, которые есть у вашего приложения, должны быть настроены для установки вместе с самим приложением. Никогда не верьте, что в среде, в которой вы собираетесь его развернуть, есть глобально установленная библиотека.
На практике
В проектах Node.js все ваши зависимости разработки и производства должны быть правильно указаны в package.json, даже те, которые в конечном итоге могут быть установлены глобально на сервере, например TypeScript.
3. Настройки
Этот фактор говорит о том, что все параметры вашего приложения, которые могут варьироваться от среды к среде (dev, HTML, test, prod и т. д.), должны быть настроены на уровне среды и никогда не должны быть жестко запрограммированы в вашем коде.
На практике
Мы делаем это в Node.js с помощью переменных среды, загружаемых через такие модули, как dotenv или dotenv-safe.
4. Службы поддержки
Этот фактор говорит о том, что все службы поддержки, в которых нуждается ваше приложение, от баз данных, таких как MySQL, до очередей в RabbitMQ, проходящих через SMTP Gateway и веб-API вашей собственной компании, должны рассматриваться в равной степени как ресурсы, внешние по отношению к вашему веб-приложению.
На практике
Обычно это требует настройки учетных данных и URL-адресов в переменных среды для каждой из этих служб, как упоминалось выше, даже если рассматриваемая служба создана вами или управляется вами. Держите свое веб-приложение слабо связанным с ними, и в будущем будет намного проще вносить изменения.
5. Скомпилировать, доставить, выполнить
Фактор «Build, Release & Run» относится к концепциям непрерывной интеграции, непрерывной доставки и непрерывного развертывания, которые часто упоминаются в книге «Экстремальное программирование».
На практике
Я вижу, что во многих компаниях это делается с помощью настройки и использования инструментов DevOps, таких как Jenkins, CircleCI, Bamboo и BitRise, которые подключаются к их репозиториям Git, и по мере того, как разработчик стремится освоить тесты, сборку, выпуск создается с новой версией, много раз запускаются новые тесты с новой версией, и она запускается в производство.
Собрать этот полностью автоматизированный конвейер CI/CD и при этом быть уверенным, что ничего не будет испорчено в процессе производства, — непростая задача, но я видел, как это происходило в некоторых компаниях, в которых я работал.
6. Процессы
12 Приложения Factor выполняются в одном или нескольких процессах без сохранения состояния, которые не обмениваются данными друг с другом. Каждый процесс, когда их несколько, является независимым и не знает о существовании других, а любые данные, которые необходимо сохранить, хранятся в базе данных.
На практике
Если ваше веб-приложение имеет серверную часть RESTful, вы будете следовать этому правилу, поскольку эта архитектура также не имеет состояния. Аналогичным образом предположим, что вы загружаете несколько процессов в свое приложение с помощью Node Cluster или PM2. В этом случае вы также будете соответствовать этому требованию, поскольку цикл событий будет разветвлен, и у вас будут процессы, работающие параллельно, даже в случае Node.js.
7. Привязка к порту
Этот фактор говорит о том, что ваше веб-приложение должно быть автономным. То есть он не зависит от веб-сервера, такого как Apache или IIS, и доступен через локальный порт для ответа на HTTP-запросы. Можете ли вы использовать команду оболочки для загрузки своего приложения, не размещая его на веб-сервере? Тогда обратите внимание на этот фактор!
В Node.js это очень просто, потому что это один из самых основных принципов технологии, верно?
8. Конкурс
Этот фактор является усилением фактора 6, поскольку лучший способ работать с параллелизмом в веб-приложениях — это иметь изолированные, независимые процессы, которые можно масштабировать как по вертикали (размещая больше ресурсов на одном сервере), так и по горизонтали. Те же советы, которые я дал для фактора № 6, применимы и здесь.
9. Одноразовый
12 приложений Factor могут быть отключены и перезапущены в любое время без существенной нагрузки на пользовательский интерфейс и потерь.
Чтобы достичь этого, вы должны сосредоточиться на быстрых запусках и остановках, которые позволяют любым ожидающим процессам завершить работу до завершения работы приложения. Даже в случае сбоев, которые неожиданно приводят к остановке вашего веб-приложения, оно должно возобновиться с того места, где остановилось, после повторного запуска.
На практике
Это поведение можно получить в Node.js с помощью таких очередей, как RabbitMQ и AWS SQS, например. Вы берете сообщение из очереди и фиксируете его только после завершения обработки. Так что, если это не по какой-то причине, перезапуск приложения снова поднимется из очереди.
10. Паритет между Dev и Prod
Короче говоря, держите все среды как можно равными. Некоторые из самых неудачных развертываний, которые я когда-либо видел, были вызваны разным фоном, поэтому все тесты, которые мы проводили до развертывания, были бесполезны, потому что конечная среда была другой.
На практике
В настоящее время широко распространенной техникой решения этой проблемы является использование контейнеров Docker, где мы запускаем локально и в других средах один и тот же образ, который будет использоваться в продакшене, только с другими конфигурациями. Другим распространенным методом является миграция с использованием некоторого ORM, такого как Sequelize, который легко гарантирует четность вашей базы данных.
11. Журналы
Этот фактор обычно не применяется, но должен. В нем говорится, что ваши журналы должны быть потоком упорядоченных событий в вашем приложении и что этот поток должен быть направлен на стандартный вывод (стандартный вывод, обычно экран консоли). Любой другой формат, который вы хотите, должен управляться средой, подключая к вашему потоку какой-либо файл, сборщик журналов и т. д.
На практике
Таким образом, в вашем приложении Node.js вы не должны явно указывать, что ваши журналы должны быть сохранены в файл или даже иметь код для управления этим файлом журнала, а вместо этого разрешить захват этого стандартного вывода журнала какой-либо внешней службой, которая будет иметь дело с их.
12. Административные процессы
В конечном итоге вам потребуется создать административные сценарии для настройки базы данных, импорта данных в приложение, преобразования старых данных в новый формат и так далее.
Эти административные сценарии, даже если они используются только один раз, должны следовать нескольким из 12 факторов, таких как № 1, № 2, № 3, № 4, № 10 и № 11.
Такие технологии, как Node.js, используют инструменты REPL для запуска административных сценариев без необходимости загрузки приложения. Тем не менее, когда это необходимо, соблюдается фактор № 7, так что сценарий является автономным приложением, для его запуска не требуется специальный веб-сервер.
Дальнейшее чтение
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord.
