Skip to content

Latest commit

 

History

History
95 lines (78 loc) · 4.46 KB

README.md

File metadata and controls

95 lines (78 loc) · 4.46 KB

Ansible Collection Development and Deployment Workflow

This document outlines the workflow for developing, reviewing, and deploying Ansible collections within Red Hat’s internal Ansible Library.

🚀 Workflow Overview

  1. Consultant Creates a Personal Branch and Develops a Collection

    • Consultant creates a personal branch off of staging.
      • git checkout -b my-feature-branch origin/staging
    • Develop a new collection or update an existing one.
    • Choose the Appropriate Namespace
      • Before creating a new collection, check the existing namespaces under the namespaces/ directory.
      • If you believe a new namespace is required, reach out to the Ansible Library Admins for approval.
    • Initialize the Collection Structure
      • ansible-galaxy collection init my_namespace.my_collection
    • Navigate to the Collection Directory
      • cd my_namespace/my_collection
    • Add Roles, Plugins, and Modules
      • Place roles in roles/
      • Add plugins in plugins/
      • Define modules in modules/
      • Include documentation in docs/
    • Define Collection Metadata
      • Edit the galaxy.yml file and ensure it includes relevant metadata such as:
      namespace: my_namespace
name: my_collection
version: 1.0.0 # If updating an existing collection please increment the version to not cause any breaks
description: A brief description of the collection.
    • Update my_namespace/my_collection/meta/runtime.yml
      • Edit my_namespace/my_collection/meta/runtime.yml file and ensure you specify a minimum required ansible version to run the collection
      requires_ansible: '>=2.9.10'
    • When ready, push changes (this automatically syncs the branch with staging). 
      git add .
git commit -m "Initialized new collection my_namespace.my_collection"
git push origin my-feature-branch
    • TODO: CICD pipeline should include the following:
      • ansible-lint to enforce best practices.
      • A customer data scrubber to prevent sensitive data leaks.

  2. Ansible Library Admins Review Changes and Merge To Main

    • Ansible Library Admins manually create a pull request from staging to main.
    • Admins review the incoming changes and approve or request modifications.
    • Incoming changes are reviewed manually for quality and security.

  3. Sync GitHub (Public) and GitLab (Private)

    • CI/CD syncs GitHub (public) → GitLab (private) to ensure they remain synchronized.
    • CI/CD pushes new changes from GitLab to GitHub after approval.

  4. Automated Collection Build & Publish

    • On the 1st of every month (or manually triggered), GitHub CI/CD pipeline:

  5. Collection Approval in Private Automation Hub

    • Ansible Library Admins review and approve the new collection.
    • Once approved, the collection becomes available to Red Hat consultants.

🔄 CI/CD Automation Breakdown

Step Trigger Action
Personal Branch Sync Consultant push to personal branch Auto-merges to staging
Staging to Main Review Manual PR creation Admins review and approve
GitHub ↔ GitLab Sync New changes in main Ensures public/private parity
Collection Build & Publish Monthly/Manual Trigger Publishes updated collections
Automation Hub Approval Manual Admin Review Makes collection available

🔧 Future Enhancements

  • Add Ansible-linter for code validation before syncing to staging.
  • Implement a customer data scrubber to prevent sensitive information in collections.
  • Introduce Slack notification alerts when collections are ready for review in Automation Hub.

📞 Contact Us

If you have any questions, need assistance, or require a new namespace, please reach out to the Ansible Library Admins:

Name Email Address
Alex Benavides [email protected]
John Best [email protected]
Walter Bentley [email protected]

For general inquiries, you can also reach us via Slack