Can you walk through the typical lifecycle of a small change that you might help us with, specifically with how it relates to coordinating changes between your team and ours?

Every change in your environment starts with submitting a pull request as our solution is built with a fully GitOps driven approach. Depending on the CODEOWNERS configuration for the repository, branch protections will require all pull requests to have approvals by specific stakeholders, in addition to requiring all checks to pass. We also try to automate as much of the review process as possible. For example, when the pull request is opened, it automatically kicks off a job to validate the change against your environment so you can see the impact of any change.

The coordination needed is simply about figuring out who will be responsible for each part of the release process. The tooling handles the rest and we have a policy-driven approach (Open Policy Agent) to enforce it.

This includes:

• Who will submit the pull request, which is entirely dependent on your comfort level with the change, or if you prefer us to take the lead.
• Reviewing the pull request and applying changes to it as needed.
• Approving and merging the pull request.
• Validating and confirming the changes.

The toolchain in your CI/CD process provides Slack notifications and full audit history of everything that happens to give you optimal visibility and traceability.

Lastly, where applicable we implement blue/green rollout strategies for releases, but there are edge cases where a change could be disruptive to active development or live services. In such cases, these would be carefully coordinated to be released at an approved time.

We recommend you first sign up for our slack team. Then join the #office-hours slack channel and ask your question there. We'll make sure to address it on our next call. Of course, you can always just join us this week and ask us there.

You're other option is to register for our FREE weekly office hours. We host these calls every Wednesday at 11:30am PT.

Cloud Posse is based in Los Angeles (PT), which is ~GMT-8 depending on the time of year. =) However, our community of more than 3,200 members is truly global. There's always someone online at any given time of the day.

We hold these sessions every Wednesday from 11:30am – 12:30pm PST (GMT-8).

Make sure to register to receive a calendar invitation.

That's a great question! Here's our philosophy:

• Learn by doing, not just by reading. First identify what you want to achieve (because you need a goal), then read and research enough to get started and go from there.
• Study our terraform modules. Every single one of our modules is a reference example for how to design and implement composable, re-usable, testable modules.
• Get started early writing tests. It's a habit hard to introduce later. We use terratest and everyone of our modules has a simple example of that.
• HashiCorp has invested heavily in their online curriculum and even offers certifications now. Their docs are free, check them out here: 
• Check out our weekly #office-hours→ cloudposse.com/office-hours (podcast.cloudposse.com and youtube.com/c/cloudposse) they are free and you can ask questions and get answers from our community of experts.
• Hangout in watering holes like this one. You'll learn a lot in a short amount of time.

We'll answer this based on our experience.

For Terraform Continuous Integration (CI), we use GitHub Actions with all of our modules. This works very well for us since we rely on GitHub. Then on a nightly basis, we run aws-nuke to clean up our environments, since failing tests frequently orphan resources that cost money and can conflict with other tests.

For a proper Terraform Continuous Delivery (CD) workflow, we think your best bet is to start with a SaaS solution and learn from that. Your options are Terraform Cloud, Scalr, Spacelift. Terraform CD is non-trivial to do well. You can easily stick Terraform into any pipeline, but a well-built terraform CD pipeline will have a terraform plan → planfile → approval → apply workflow. You'll need to stash the planfile somewhere and the planfile may contain secrets.

Unfortunately, we're not able to take on small engagements. You can, however, join us every single week for 100% free “Office Hours”—where we seek to answer your questions. Just register for an invitation.

We hold our “Office Hours” every Wednesday at 11:30 am PT via Zoom. We're typically 30+ people on the call and all skill levels are welcome.

Checkout our past recordings on YouTube or subscribe to our Podcast.

• Gruntwork doesn't provide open access to all their modules, they are a subscription service. Cloud Posse open sources everything.
• All of our code is in GitHub and can be forked and used with no concerns about licensing issues (APACHE2).
• Gruntwork does not help with hands-on implementation. That's left up to you.
• We provide a comprehensive project plan consisting of hundreds of implementation tasks and design decisions that we execute together with your team.
• Our Slack community is free for anyone to join, not just paying customers.
• Because our work is Open Source, there's a lower barrier to getting started. That's why it's in use by thousands and thousands of companies. We receive dozens of Pull Requests every week enhancing our modules and fixing bugs.

You do not need to be a customer to benefit from our community. We have a VERY active and helpful public slack community. Go to slack.cloudposse.com.

Cloud Posse is not affiliated with the github.com/terraform-aws-modules repository, but many users of this organization participate in our SweetOps slack team in the #terraform-aws-modules channel.

SweetOps is a community that is run by Cloud Posse. It exists as a place for our users to collaborate and ask questions related to our large collection of open source projects on GitHub, but also to talk shop and get feedback on anything DevOps related.

Cloud Posse does offer documentation as part of the engagements but the audience is for experienced developers, so if different documentation is required, these can be created upon request.

1. We start with baseline using modules from our repo that are ready to use for our customers. This is simply a remote reference to our modules. These modules are well maintained and all changes upstream are managed using releases, so you can do version pinning
2. We find as we work with customers over time that as their confidence increases, they begin modifying these modules to fit their own needs, which is expected.

Anyone is free to fork our repositories and try themselves, but our support eliminates the guesswork and shortens the time it takes to implement correctly.

Think of it like this: anyone can walk into a hardware store and pick up the materials to build a house. Very few people can build a house that won't fall down if they don't have the experience of using all the tools and hardware correctly. We fill the gap by providing the knowledge and experience to get you where you want to be faster than doing it yourself.

We're a motley crew of software engineers who all found their calling in DevOps/SRE arena. We have a mix of complementary skill sets that help us work with a diverse range of companies. Everyone on our team has years of software development experience. We believe this is essential because developers are fundamentally against doing things over and over by hand.