Назад | Перейти на главную страницу

Как несколько DevOps могут управлять одной поваренной книгой?

Я создал кулинарную книгу и использую manage.chef.io разместить и развернуть его. Я разместил кулинарную книгу в частном репозитории GitHub.

Рассмотрим сценарий:
Если я внесу какие-то изменения в кулинарную книгу и knife cookbook upload это, но я забудь нажать это в Github.

Как мне убедиться, что этого не произойдет? Даже не по ошибке. Как мне убедиться, что каждый раз имеет последнее репо и не может knife upload это иначе. Так же, как ты не можешь git push если у вас нет git pullвнес изменения.

Мой коллега извлекает из GitHub, но не видит изменений. Таким образом он вносит свои изменения и knife cookbook upload Это. Но он заменит мои изменения, так как у него старая версия.

Итак, как лучше всего управлять кулинарной книгой среди нескольких DevOps?

Самый простой подход - сделать так, чтобы отправка на Chef Server находилась под контролем вашей CI-службы, такой как Jenkins. Это вызывает сериализацию вокруг системы управления версиями, поскольку ни один человек не имеет прав на загрузку поваренной книги. Вы также можете просто убедиться, что общаетесь достаточно, чтобы избежать этого, но это гораздо более подвержено ошибкам. Некоторые рабочие процессы Chef, связанные с файлами политик, не имеют этой проблемы, поскольку вообще не используют обычные загрузки поваренной книги.