cloudfoundry: совместное использование пространства несколькими разработчиками - PullRequest
0 голосов
/ 17 февраля 2019

с облачным ландшафтом на платформе sap cloud, я смотрел на подход / лучшие практики, когда несколько разработчиков работают над одним приложением.

Должен ли каждый разработчик иметь отдельное пространство и должен толкать приложение каждый раз, когда онихотите проверить?или

Должно ли быть одно пространство для «девопмента» с несколькими приложениями и какой-либо вид совместного использования услуг между различными приложениями, которые будет продвигать каждый разработчик?,В этом подходе я вижу проблемы, если я изменяю службу (например, db), которая может повлиять на другие приложения, которые совместно используют ее.

Я просмотрел документацию, но не получил никаких подсказок о нескольких разработчиках, работающих в пространстве., поэтому любой совет / опыт высоко ценится

Ответы [ 2 ]

0 голосов
/ 18 февраля 2019

Я не думаю, что кто-то может сказать вам, что имеет смысл для вашей организации.Вам нужно подумать о том, как вы хотите организовать своих пользователей, приложения и пространства.Управление квотами играет важную роль в этом, но и доступ к приложениям и услугам.

Что нужно учитывать:

  1. Кому нужен доступ к приложениям, которые вы помещаете в пространство?Вы можете управлять этим с помощью ролей пространства (Space Dev, Manager & Auditor).

  2. Как вы хотите управлять пространствами?Это даст вам некоторое представление о том, как вы хотите структурировать свои организации.Права организации позволяют оператору делегировать управление кому-либо еще (руководителю организации, аудиторским ролям).

  3. Как вам нужно ограничивать ресурсы, которые потребляют ваши пользователи?т.е. квоты.Вы можете применять квоты к организациям и пробелам.Подумайте, как вы хотите ограничить возможности групп.

  4. Рассмотрите границы org / space.Нужно ли вам делиться такими вещами, как услуги, между организациями и пространствами?Есть некоторые возможности сделать это через фонд, но будьте осторожны, потому что отдельные сервисные брокеры также должны поддерживать это.На момент написания некоторые делают, а некоторые нет.Те, кому это не нужно, должны быть предоставлены в менее удобном для пользователя сервисе.

    https://docs.cloudfoundry.org/devguide/services/sharing-instances.html

  5. Подумайте, нужно ли вам выставлять счета или производить возврат платежей.Делать это для каждой организации / пробела имеет смысл, поэтому вам нужно будет согласовать это с тем, как вы делаете выставление счетов / возврат платежей.

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

  1. В командах, где разработчики управляют на протяжении всего цикла, я видел, как организациииспользуется для группировки команд разработчиков, а пространства используются для группировки проектов или приложений.Таким образом, команда A имеет доступ к организации A, которая имеет пробелы X, Y и Z для приложений X, Y и Z. Приложения X, Y и Z развертывают dev, test, qa и prod в одном и том же пространстве.

  2. В компаниях с более традиционными структурами, где команды разработчиков передают код рабочей группе, я обычно вижу организации и пробелы, чтобы облегчить это разделение.У разработчиков есть свои собственные организации и места для разработки и тестирования.У Ops есть свои организации и помещения для производства.Эти два не смешиваются.

Есть также варианты этого, так что еще раз подумайте, что имеет смысл для вас и вашей компании.

Надеюсь, что помогает!

0 голосов
/ 18 февраля 2019

Пространства в Cloud Foundry имеют функциональную цель - обеспечить управление квотами и контроль над группой людей.Таким образом, вы должны структурировать пробелы в зависимости от вашей необходимости изолировать / контролировать приложения.

Наиболее распространенный вариант использования пробелов: - dev / qua / prod - Department_a / deparment_b; ..

Что касается разработки общих сервисов, пожалуйста, убедитесь, что вы понимаете сервисы CF. Они предоставляют механизм, отличный от обычных приложений, например, экземпляр сервиса (например, БД) может использоваться несколькими приложениями в разных пространствах:

https://docs.cloudfoundry.org/devguide/services/sharing-instances.html

...