DevOps Studio

Appearance

Contributing to DevOps Studio ​

Thank you for your interest in contributing to DevOps Studio! This document provides guidelines for contributing and outlines our roadmap for future enhancements.

What is CONTRIBUTING.md? ​

CONTRIBUTING.md is a standard file in open-source projects that:

  1. Guides Contributors - Explains how to contribute code, documentation, or improvements
  2. Sets Expectations - Defines coding standards, review process, and contribution workflow
  3. Documents Roadmap - Shows planned features and areas where contributions are welcome
  4. Establishes Community - Welcomes contributors and explains how to get help

This file helps maintain quality and consistency as the project grows.

Table of Contents ​

How to Contribute ​

Types of Contributions ​

We welcome various types of contributions:

  • 🐛 Bug Reports - Found an issue? Report it!
  • ✨ Feature Requests - Have an idea? Share it!
  • 📝 Documentation - Improve explanations or add missing docs
  • 🧪 New Labs - Contribute additional learning scenarios
  • 🔧 Bug Fixes - Submit pull requests for fixes
  • 📊 Testing - Help validate labs in different environments
  • 💡 Improvements - Enhance existing labs with better patterns

Contribution Process ​

  1. Fork the repository
  2. Create a feature branch (git checkout -b feature/amazing-lab)
  3. Make your changes
  4. Test thoroughly
  5. Document your additions
  6. Commit with clear messages
  7. Push to your fork
  8. Submit a pull request with a clear description

Contribution Guidelines ​

Code Standards ​

  • Follow existing patterns - Match the style and structure of existing labs
  • Write clear code - Code should be self-documenting with comments where needed
  • Test your changes - Ensure everything works before submitting
  • Update documentation - Keep READMEs and docs current

Documentation Standards ​

  • Comprehensive READMEs - Each lab needs a detailed README
  • Clear instructions - Step-by-step guides for first-time users
  • Troubleshooting sections - Document common issues and solutions
  • Cost information - Include cost estimates and optimization tips

Commit Messages ​

Use clear, descriptive commit messages:

bash
# Good
git commit -m "Add service mesh lab with Istio and Linkerd examples"

# Bad
git commit -m "updates"

Pull Request Guidelines ​

  • Clear title - Describe what the PR does
  • Detailed description - Explain the changes and why
  • Link issues - Reference related issues
  • Screenshots - Include screenshots for UI changes
  • Testing notes - Describe how you tested

Lab Contribution Standards ​

When contributing new labs, follow these standards:

Required Components ​

  1. README.md - Comprehensive documentation including:

    • Overview and objectives
    • Prerequisites
    • Step-by-step setup instructions
    • Usage examples
    • Troubleshooting
    • Cost considerations
    • Learning objectives

  2. Working Code - Not just documentation:

    • Terraform configurations (if applicable)
    • Scripts and automation
    • Example applications
    • Configuration files

  3. Makefile - Automation commands:

    • make init - Initialize environment
    • make apply / make deploy - Deploy resources
    • make destroy - Cleanup resources
    • make validate - Validate setup
    • make test - Run tests

  4. Validation Scripts - Ensure everything works:

    • scripts/validate.sh - Validate deployment
    • scripts/test.sh - Run tests

  5. Cost Information - Help users manage costs:

    • Monthly cost estimates
    • Cost to complete estimates
    • Optimization tips

Lab Structure ​

Follow the established directory structure:

labs/XX-lab-name/
├── README.md                    # Comprehensive documentation
├── Makefile                     # Automation commands
├── main.tf                      # Terraform (if applicable)
├── variables.tf                 # Variables
├── outputs.tf                   # Outputs
├── terraform.tfvars.example     # Example configuration
├── scripts/                     # Automation scripts
│   ├── validate.sh
│   └── test.sh
└── [lab-specific directories]   # Lab-specific components

Quality Checklist ​

Before submitting a lab, ensure:

  • ✅ All code is tested and working
  • ✅ Documentation is complete and clear
  • ✅ Cost estimates are included
  • ✅ Cleanup instructions are provided
  • ✅ Validation scripts work
  • ✅ Follows existing lab patterns
  • ✅ No hardcoded credentials or secrets
  • ✅ Error handling is included
  • ✅ Best practices are demonstrated

Roadmap ​

This section outlines planned additions and areas where contributions are especially welcome.

🎯 High Priority (Next Labs) ​

These are the next labs we plan to add:

Lab 09: Service Mesh ​

Status: Planned
Focus: Service-to-service communication, traffic management, security

Technologies:

  • Istio
  • Linkerd
  • Service mesh patterns
  • mTLS
  • Traffic splitting and canary deployments

What it will cover:

  • Service mesh architecture
  • Istio installation and configuration
  • Linkerd setup
  • Traffic management policies
  • Security policies (mTLS)
  • Observability in service mesh

Estimated Time: 2-3 hours
Difficulty: Advanced

Lab 10: FinOps & Cost Optimization ​

Status: Planned
Focus: Cloud cost management, optimization, and governance

Technologies:

  • AWS Cost Explorer
  • AWS Budgets
  • Cost allocation tags
  • Reserved Instances
  • Spot Instances
  • Right-sizing tools

What it will cover:

  • Cost visibility and reporting
  • Budget alerts and governance
  • Resource tagging strategies
  • Cost optimization techniques
  • Reserved Instance planning
  • Spot instance usage
  • Cost anomaly detection

Estimated Time: 2-3 hours
Difficulty: Intermediate

🔮 Future Labs (Ideas) ​

These are potential future additions:

Lab 11: Multi-Cloud Operations ​

  • Multi-cloud strategies
  • Terraform multi-cloud patterns
  • Cloud-agnostic architectures
  • Disaster recovery across clouds

Lab 12: Edge Computing ​

  • AWS Outposts
  • Edge locations
  • CDN optimization
  • Edge-native applications

Lab 13: Data Engineering Platform ​

  • Data lakes (S3, Lake Formation)
  • ETL pipelines (Glue, Airflow)
  • Data warehouses (Redshift, Snowflake)
  • Data streaming (Kinesis)

Lab 14: AI/ML Operations (MLOps) ​

  • SageMaker pipelines
  • Model deployment
  • Model monitoring
  • Feature stores

Lab 15: Chaos Engineering ​

  • Chaos Monkey
  • Fault injection
  • Resilience testing
  • Failure scenarios

🛠️ Platform Improvements ​

Areas where contributions are welcome:

Documentation ​

  • Additional tutorials
  • Video walkthroughs
  • Architecture diagrams
  • Best practices guides

Tooling ​

  • Additional automation scripts
  • Validation improvements
  • Cost estimation tools
  • Testing frameworks

Labs Enhancement ​

  • Additional service catalog templates
  • More CI/CD examples
  • Additional monitoring dashboards
  • Security policy examples

How to Contribute to Roadmap Items ​

Proposing a New Lab ​

  1. Open an Issue - Create a GitHub issue describing the proposed lab
  2. Get Feedback - Discuss the idea with maintainers
  3. Create Proposal - Document the lab structure and learning objectives
  4. Get Approval - Wait for maintainer approval
  5. Start Building - Create the lab following contribution standards

Working on Roadmap Items ​

  1. Check Issues - Look for existing issues for roadmap items
  2. Comment - Express interest in working on an item
  3. Get Assigned - Wait for maintainer assignment
  4. Follow Standards - Build according to lab contribution standards
  5. Submit PR - Create pull request when complete

Getting Help ​

Questions? ​

  • 💬 GitHub Discussions - Ask questions and share ideas
  • 🐛 GitHub Issues - Report bugs or request features
  • 📧 Email - Contact maintainers for complex questions

Code Review Process ​

  1. Submit PR - Create pull request with clear description
  2. Automated Checks - CI/CD will run validation
  3. Review - Maintainers will review code and documentation
  4. Feedback - Address any feedback or requested changes
  5. Merge - Once approved, your contribution will be merged!

Recognition ​

Contributors will be:

  • Listed in the project (if desired)
  • Credited in lab documentation
  • Acknowledged in release notes

Code of Conduct ​

Our Standards ​

  • Be respectful - Treat everyone with respect
  • Be inclusive - Welcome diverse perspectives
  • Be constructive - Provide helpful feedback
  • Be patient - Everyone is learning

Unacceptable Behavior ​

  • Harassment or discrimination
  • Trolling or inflammatory comments
  • Personal attacks
  • Any other unprofessional conduct

License ​

By contributing, you agree that your contributions will be licensed under the same license as the project (MIT License).

Thank you for contributing to DevOps Studio! 🎉

Your contributions help make DevOps education more accessible and practical for everyone.

Released under the MIT License.

DevOps Studio - architecture decisions, implementation patterns, and operational readiness.