Как практик DevOps, я на протяжении многих лет имел большой опыт работы, связанной с непрерывной доставкой. Кажется, что, по моему мнению, концепция «Управление конфигурацией программного обеспечения (SCM)» была популярна много лет назад, и я редко обращаю на нее внимание. или даже упомянуть эту концепцию позже. Недавно я встретил некоторых людей и вещи, связанные с «управлением конфигурацией», которые заставили меня проанализировать и задуматься о взаимосвязи между «управлением конфигурацией» и организационной структурой, а также построением системы DevOps.

Что такое управление конфигурацией?

Честно говоря, люди с разным опытом работы имеют разное понимание и позиционирование управления конфигурациями. Ниже я кратко объясню свое понимание из нескольких различных областей.

Определение ITIL управления конфигурацией

В ITIL (Библиотека ИТ-инфраструктуры, стандартная библиотека ИТ-инфраструктуры) управление конфигурацией (Управление конфигурациями) является ключевым компонентом. Его определение включает в себя идентификацию, запись, контроль и управление элементами конфигурации (Элементы конфигурации, CI) в процессе проверки ИТ-услуг. .

В частности, управление конфигурацией направлено на обеспечение того, чтобы элементы конфигурации (такие как компьютерные системы, серверы и другие активы) были точными и надежными, а также соответствовали их требованиям, проектированию и операционной информации на протяжении всего их жизненного цикла. Это системная инженерия, которая устанавливает и поддерживает производительность, функциональность и физические характеристики продукта. Цели управления конфигурацией в основном включают в себя два аспекта:

• Одним из них является ведение базы данных Конфигурация регулирования (Конфигурация Management Database, CMDB) записи каждой ИТ-инфраструктуры;
• Второе — предоставление отчетов по элементам конфигурации (CI).,Содержит записи о проблемах、История изменений、Информация о версии、информация о статусе、Информация о взаимоотношениях и другая управляющая информация.

В частности, управление конфигурацией — это автоматизация настройки, мониторинга, управления и обслуживания всех объектов инфраструктуры и систем, таких как серверы, приложения, хранилища, сети и все размещенные службы.

Чтобы система управления конфигурацией функционировала, ей требуется некий механизм хранения информации, которой она управляет. Первоначально это называлось базой данных управления конфигурациями (CMDB); в ITIL V3 была представлена ​​концепция системы управления конфигурациями (CMS), которая заменила CMDB. CMDB продвигает концепцию единого монолитного репозитория, в то время как CMS предоставляет концептуальные системы CMDB, которые работают вместе для поддержки потребностей этого процесса управления.

image.png

Определение управления конфигурацией в DevOps

В практике DevOps управление конфигурацией часто сочетается с автоматизированными процессами, такими как непрерывная интеграция (CI) и непрерывное развертывание (CD), для достижения быстрого, надежного и последовательного развертывания от отправки кода до производственной среды. Кроме того, автоматизированное управление конфигурацией обеспечивает согласованность между средами, поддерживая согласованные настройки при разработке, тестировании или производстве. Конкретные практики включают в себя следующие аспекты:

• Контроль версий кода
• развертывание автоматизации (такие как Ansible, Puppet, Chef и т. д., их часто рассматривают как инструменты автоматизации конфигурации управления)
• полагатьсяуправлять
• Шаблоны инфраструктуры (например, Terraform, ARM и т. д.)
• ...

Введение в управление конфигурацией в CMMI

В CMMI (Capability Maturity Model Integration, Capability Maturity Model Integration) управление конфигурацией является важным компонентом, используемым для обеспечения целостности, согласованности и отслеживаемости программных продуктов, а также процессов их разработки и жизненных циклов.

Управление конфигурацией в CMMI в основном достигается за счет следующих ключевых действий:

image.png

1. Логотип конфигурации: для программных продуктов и различных элементов конфигурации (например, документов), находящихся в процессе разработки.、исходный код, спецификация, ошибка и т. д.) для идентификации,Чтобы эти элементы конфигурации можно было точно идентифицировать и использовать в последующих процессах разработки и обслуживания.
2. Контроль версий: история изменений элементов через системы контроля версий (такие как Git, SVN и т. д.).,Убедитесь, что каждый элемент конфигурации имеет четкую информацию о версии и записи об изменениях. Это помогает быстро найти источник проблемы, если она возникает.,и принять соответствующие меры по ремонту.
3. Базовое управление: базовое состояние — это набор элементов конфигурации, которые были официально рассмотрены и утверждены.,как основа дальнейшего развития. В CMMI,Управление базовым состоянием включает в себя процесс установления, изменения и проверки базового уровня.,Гарантировать, что программные продукты могут соответствовать заранее установленным стандартам и требованиям качества на разных этапах.
4. Аудит конфигурации: проверьте, является ли версия элемента конфигурации в базовом варианте правильной и согласованной с помощью аудита конфигурации.、Местоположение правильное?、Соответствует ли оно своему функциональному описанию?ждать。Это помогает обеспечить целостность и согласованность программного продукта.,и снизить потенциальные риски и проблемы.

Управление конфигурацией в CMMI делает упор на всесторонний контроль и управление программными продуктами и процессами их разработки, обеспечивая качество и удобство сопровождения программных продуктов с помощью технических и административных средств.

Разное «управление конфигурацией» решает разные проблемы.

Управление конфигурациями в сфере ITIL – управляйте ИТ-активами и контролируйте ежедневные изменения

Управление конфигурациями в основном решает следующие проблемы:

• Инструмент «Конфигурация регулирования» улучшает анализ влияния изменений для организаций.,Сократите время простоев, вызванное изменениями в производстве.
• Конфигурация регулирования сочетает в себе эффективную модель обслуживания,Сопоставление взаимозависимостей элементов конфигурации и связь между элементами конфигурации и запросами на изменение.,чтобы помочь быстрее восстановить обслуживание во время сбоя.
• Система Конфигурация направляет обеспечивает аудит и поддержку соответствия при историческом оперативном учете оборудования, его использования и модификаций.

image.png

Управление конфигурацией в CMMI, контролирующее изменения в процессе разработки программного обеспечения.

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

На рисунке ниже показан снимок экрана управления конфигурацией, найденный в определенном программном обеспечении для управления проектами в Интернете. На самом деле предполагается, что многие организации будут использовать таблицы Excel для управления этой деятельностью через некоторые системы процессов.

Управление конфигурациями в сфере DevOps — отслеживайте изменения на уровне инструментов автоматизации, всё — код

CMMI выдвигает нормативные требования с макроэкономической точки зрения, но, похоже, не говорит организациям, как их реализовать? Кроме того, идея управления конфигурацией CMMI по-прежнему основана на «централизованном управлении кодом», похоже, она не предполагает «распределенного управления кодом», представленного git, поэтому в реальной реализации отклонение будет еще больше. По этому поводу, пожалуйста, оставьте сообщение для обсуждения.

В системе DevOps управление конфигурацией программного обеспечения является краеугольным камнем «всякой автоматизации» (PS: Будьте более приземленными и сталкивайтесь с проблемами лицом к лицу)。Резюме：включить все Конфигурацияуправлять,Следите за программным обеспечением 3 основной принцип：Все версировано; общий источник доверия; стандартизация и автоматизация;

1) У всего есть версия,относится к：Когда вам нужно выпускать программное обеспечение быстрее,В процессе производства программного обеспечения необходимо осуществлять соответствующий контент.,Этот контент — не просто исходный код,Конфигурациядокумент,Данные операции,Также включает в себя: набор инструментов для тестирования или библиотеку тестирования.,Код, связанный с тестом,данные испытаний,Тестовые сценарии и т. д.

2) Поделитесь одним надежным источником,Относится к: всей организации необходимы все склады группы исследований и разработок: склад требований, склад кода, склад пакетов программного обеспечения. Все члены команды должны сравнивать содержимое этих складов и сотрудничать друг с другом, чтобы гарантировать, что информация, полученная всеми участниками, является достоверной. правильные. Среди хранилищ пакетов, в том числе 3 типа: временный склад продуктов, официальный склад пакетов релизов, внешний частный серверный склад пакетов программного обеспечения.

3) Стандартизация и автоматизация,Относится к: Конфигурация программного обеспечения должна разработать соответствующие стандарты и спецификации.,Например：Стратегия ветвей, наименование ветвей, наименование тегов ветвей, наименование и место хранения функций продукта, структура каталогов исходного кода.ждать。Когда члены группы исследований и разработок понимают и соблюдают эти стандарты испецификацияназад,Это может не только сократить ненужные расходы на связь,Вы также можете выполнять больше повседневных рутинных операций, автоматизация,тем самым высвобождая больше человеческих ресурсов,И значительно уменьшить различные ошибки, вызванные ручными операциями.

версия.jpg

Суммируя,Через инструменты DevOps и упражняться,Правильное использование и внедрение Конфигурации регулирования гарантирует контроль.,Точность, отслеживаемость, возможность восстановления, согласованность, эффективность и контроль версий.。

Проверьте, хорошо ли команда исследований и разработок поработала над управлением конфигурацией.

Вы можете использовать следующие 5 вопросов, чтобы проверить, все ли версии созданы командой исследований и разработок:

• Вопрос 1. Занесены ли исходные коды продуктов и тестовые коды в систему контроля версий?
• Вопрос 2. Внесена ли информация о конфигурации программного приложения в систему контроля версий?
• Вопрос-3: Внесены ли в систему контроля версий системы Конфигурация различных операционных сред?
• Вопрос-4: Занесены ли в систему контроля версий скрипты сборки и развертывания автоматизации?
• Вопрос 5. Была ли установлена ​​версия пакета программного обеспечения?

Команда исследований и разработок также может попробовать проверить, достаточно ли хорошо реализовано управление конфигурацией программного обеспечения:

• Q-S1：Только из источникарепозиторий Товары обнаружены в кодисходном код,Можете ли вы создать полный пакет приложений одним щелчком мыши?
• Вопрос-S2: Без помощи других,Любой член группы исследований и разработок может создать систему прикладного программного обеспечения одним щелчком мыши.,Используется ли он для знакомства с новыми функциями продукта?

Мысли о реализации управления конфигурацией программного обеспечения

Вышеуказанное представило определение и практику управления конфигурацией в различных аспектах, но как насчет его реализации? Именно по этой причине я написал эту статью. Я нашел два объявления о вакансиях, иллюстрирующих эту проблему.

Опирается ли «управление конфигурацией» на процессы (людей) или инструменты?

Традиционное управление конфигурацией (CMMI) по-прежнему больше полагается на [людей] для [охраны] процессов и правил. Если организация/команда невелика или техническая структура унифицирована, и если нет возможности автоматизации платформы, можно полагаться на [людей], которые пройдут [Охрану] (PS: предпосылка заключается в том, что все уважают процесс и соглашение).

Если команд и стеков технологий много, полагаться на людей практически невозможно. Даже с помощью некоторых инструментов это действительно зависит от уровня «инженера по управлению конфигурациями».

«Управление конфигурацией» и организационная структура

Предполагается, что только более крупные компании имеют так называемую роль «инженера по управлению конфигурацией». Так какой же отдел подойдет на эту роль?

• Приписан к организационному уровню управления отделом: наверху храма.,По сути, контролирующая роль,Очень слабый контроль над фактической деятельностью по НИОКР по проекту. Если есть много предприятий/команд,В принципе бесполезно.
• Назначен команде исследований и разработок: если команда большая (например, более 100 человек) и бизнес один, этот человек в основном интегрируется в команду исследований и разработок и лучше знакомится с бизнесом.

Будущее «управления конфигурацией» по-прежнему за автономией команды.

Как практик DevOps,Я предпочитаю ослабить сам процесс «Конфигурация регулирования». Поговорите об этом больше,Разве «Конфигурация направляет» не весь ваш процесс исследований и разработок? От проблемы к коду,Затем к продуктам и окружающей среде,Какая ссылка оставляет слово «изменить»?,Ядром управления конфигурацией на самом деле является «контроль изменений».

так,Поднимите шум по поводу изменений (создайте правила,Инструменты сборки）。Проще говоря, я говорю команде, что проблему необходимо откатить, и я могу найти стабильную версию (или быстро сгенерировать стабильную версию) за короткое время (в течение 5 минут) и быстро развернуть ее в назначенном месте. В основном «Управление конфигурацией» выполнено. Нет, планы/изменения управления конфигурацией — это мертвая буква.

Создавissue-code-artifact-environment Команда может полностью реализовать самоуправление «управлением конфигурацией» вручную посредством автоматизации.

ссылка

• https://www.cmcrossroads.com/article/seven-lessons-you-learn-when-growing-your-configuration-management