Ответ
Я версионирую роли Ansible, используя семантическое версионирование (SemVer) в связке с Git. Основная версия указывается в meta/main.yml роли, а контроль версий осуществляется через Git-теги.
1. Структура meta/main.yml:
galaxy_info:
role_name: my_nginx_role
author: DevOps Team
description: Nginx configuration and deployment role.
license: MIT
min_ansible_version: "2.9"
platforms:
- name: Ubuntu
versions:
- "20.04"
- "22.04"
galaxy_tags:
- web
- nginx
- proxy
dependencies: []
# Ключевое поле для версии роли.
version: 2.1.0
2. Работа с Git (практика):
# После внесения изменений и тестирования создаем тег, соответствующий версии из meta/main.yml.
git add .
git commit -m "feat: add TLS 1.3 support"
git tag -a v2.1.0 -m "Release version 2.1.0 with TLS 1.3"
git push origin main --tags
3. Использование версионированных ролей в requirements.yml:
# Установка роли из Git-репозитория по конкретному тегу.
- src: https://github.com/my-org/ansible-role-nginx.git
scm: git
version: v2.1.0 # Явное указание версии (тега)
name: nginx_role
# Или из Ansible Galaxy, если роль опубликована там.
- src: geerlingguy.nginx
version: "4.1.0"
Моя стратегия версионирования:
- MAJOR (X.0.0): Изменяю при несовместимых изменениях API роли (например, переименование обязательной переменной
nginx_portвweb_port). - MINOR (1.X.0): Изменяю при добавлении новой функциональности без нарушения обратной совместимости (добавление поддержки нового модуля).
- PATCH (1.0.X): Изменяю для исправления ошибок и багов.
Это позволяет команде безопасно обновлять роли в проектах, указывая в requirements.yml диапазоны версий (например, version: ">=2.0.0, <3.0.0").