Мне интересно, как проекты, в которых есть несколько команд, управляют своими наборами кулинарных книг?
Мы пытаемся выяснить, как мы можем сделать так, чтобы команда операторов предоставила набор рецептов «общих компонентов», которые могут быть повторно использованы другими командами, которые также будут писать свои собственные кулинарные книги. Например, операционная группа должна владеть кулинарной книгой Java, в то время как компонент управляет своими кулинарными книгами, написанными для их компонентов или механизмов сборки.
Судя по моему небольшому опыту работы с сервером шеф-поваров, этот вид рабочего процесса не очень хорошо поддерживается, поскольку сервер хранит и управляет всеми кулинарными книгами, поэтому есть вероятность перезаписать поваренную книгу, написанную другой командой.
Как другие проекты решают такие проблемы?
Система контроля версий (например, мерзавец который Майкл Хэмптон упомянул) - обычное решение этой проблемы: ваши команды редактируют свои кулинарные книги и хранят их в репозитории git, а сервер проверяет их, когда приходит время отправлять конфигурации.
Здесь есть немного дополнительной сложности (вы хотите убедиться, что ваши кулинарные книги не перекрывают друг друга и не создают конфликтов), но это можно решить с помощью контроля человеческого фактора (убедитесь, что ваши команды общаются друг с другом) или если вы Вы амбициозны, вы можете использовать git-хуки, чтобы программно гарантировать, что у вас не возникнут проблемы.
Хранение ваших кулинарных книг в системе контроля версий имеет и другие преимущества - например, возможность разветвлять их для разработки и легко вернуться к предыдущей редакции, если вы обнаружите что-то ужасно сломанное.