Коэффициент кодовой базы приложения 12Factor, который следует разделить

Недавно я был весьма соблазнен приложением 12Factor, так как это строгое руководство, которому я должен заставить себя следовать. Поэтому в проекте, над которым я сейчас работаю, я решил использовать их. Хотя у меня есть сомнения относительно моей структуры кода:

У меня есть веб-сайт, который просто создаст новые рабочие места, и люди могут ознакомиться с результатами работы там. Задания ставятся в очередь в распределенной очереди (ftm Redis), и рабочие берут каждое задание и выполняют его. Я решил разделить кодовую базу на 2 части:

  • фактический сайт, который будет ставить задания в очередь, и пользователи будут получать доступ к результату.
  • работники, которые полностью автономны.

В середине есть пакет узла, который инкапсулирует связь (постановка в очередь и т. д.), и связь между узлами осуществляется только через Redis.

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

Спасибо за вашу помощь


node.js heroku 12factor
person charly    schedule 28.04.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Будьте проще, но не проще, чем имеет смысл. Если вам проще хранить все это в одной кодовой базе, начните с этого. Разработка — это итеративный процесс, предполагайте, что вы делаете что-то неправильно, и будьте готовы изменить вещи, когда они станут слишком громоздкими.

Преждевременная оптимизация (или абстракция) вашего кода (или рабочего процесса) всегда неразумна.

person Eric Fode    schedule 28.04.2013
comment
Это верно. Однако создание его в единой кодовой базе заставит его полагаться на зависимости, которых на самом деле не существует (например, я думаю о экспрессе). Но это правда, что одна кодовая база упростит все, включая развертывание. - person charly; 29.04.2013
comment
Я думаю, что я бы начал с одного, и когда вы обнаружите, что можете поддерживать их как систему приложений, а не как приложение, разделите его на части. Мы делаем это в героку довольно часто. Мы начнем что-то писать, а затем заметим, что между компонентами приложения существует ненужная связь, и разделим их на систему приложений при их рефакторинге. - person Eric Fode; 29.04.2013

arrow_upward
1
arrow_downward

Я решил разделить кодовую базу на 2 части.

Что ж, первый пункт на веб-сайте 12 факторов гласит: «Одна кодовая база отслеживается в системе контроля версий, множество развертываний».

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

person BraveNewCurrency    schedule 28.04.2013
comment
Если бы оба могли использоваться как независимые части программного обеспечения и могли бы поддерживаться как таковые, возможно, имело бы смысл держать их отдельно. - person Eric Fode; 29.04.2013
comment
Да, что заставило меня колебаться: если есть несколько кодовых баз, это не приложение — это распределенная система. Каждый компонент в распределенной системе представляет собой приложение, и каждый по отдельности может соответствовать двенадцати факторам. - person charly; 29.04.2013
comment
Да, это компромисс, правильного ответа нет. Составьте список функций, которые вы, вероятно, добавите в следующий раз. Сколько потребуется коснуться обеих кодовых баз? Если это большинство из них, подумайте о том, чтобы снова объединить их в 1 репо. - person BraveNewCurrency; 29.04.2013