You can't just say "we do DevOps" anymore. If DevOps best practices aren't followed, teams inevitably waste the potential gains that DevOps practices enable, and infrastructure problems still aren't resolved.

With the continued success of DevOps and Infrastructure as Code(IaC) conversions, it's no wonder that IT teams across the world are adopting these new practices.

Ready to get started? The first DevOps best practice you need to know is the separation of application and operations repositories. Avoid common pitfalls by using Bitovi's recommended DevOps practices. You'll learn what an OpsRepo is and why and how to separate your application and operation logic into their own repositories.

What Happens Without Best Practices?

When your DevOps team doesn't invest in proper operation management practices, you end up with slow, unaware infrastructure provisioning, redundant resources eating up infrastructure budget, and a critical failure point where all the knowledge of the infrastructure and its configuration is held by just one or two people.

Managing application infrastructure can be frustrating and prone to error. Configuration, builds, tagging and deployments are just a few of the many vectors SREs need to consider to create successful CI/CD pipelines.

And if these resources are handled through logging on to a server or clicking buttons on a cloud console, aka  ClickOps, the complexity of configuration management and the likelihood for error grows.  

A common challenge for any established website or application is migrating to a cloud-based provider.  When hardware is too old, paid dedicated hosting plans are no longer cost effective, or the current service can't effectively scale, you may need to migrate.

Moving to a cloud-based provider is complex. Entire areas of knowledge and terminology need to be digested, a daunting task for any developer or team.

Having some way to play around with multiple cloud technologies while keeping your whole process adaptable makes BitOps the perfect testbed for your DevOps efforts! 

Last Updated: December 07, 2022

HeyEmoji is a fantastic reward system teams can use to recognize each other's accomplishments, dedication, and hard work. Once you get it set up, you can mention a colleague's Slack username in any channel along with a pre-configured reward emoji - you can even include a short description of what they did that was so awesome it deserved a shoutout.

The best part? When you send an emoji to a colleague, they get emoji points, which can be tracked on a leaderboard. Competing to see who can be most helpful, considerate, or skilled at their jobs is a pretty fun way to make the day fly by. 

Want to get HeyEmoji on your own work Slack channel? This tutorial walks you through how to deploy the HeyEmoji Slack app to AWS using Terraform+Ansible so your team can enjoy Slack-generated kudos. 

In a recent series of blog posts, I drew up how to go from a basic StackStorm installation and pack deployed using Ansible, to moving that entire custom deployment to a one-touch cloud deployment using BitOps while only modifying a handful of files in the process.

We only barely scratched the surface of our implementation, and we can always go further. One aspect I tried to be mindful of throughout the guides was the various ways of managing of secrets. In this guide we will detail how we can utilize an AWS Key Management Service (KMS) key as well as AWS Systems Manager (SSM) and Parameter Store to take that a step further.

In practical terms: we'll create a BitOps before hook script we use to retrieve all of the secret variables we need from AWS, and demonstrate how we can load those into the BitOps container environment for usage within our existing Ansible StackStorm playbook.

Last time, we had refactored our basic one-line install of StackStorm and our custom pack into an Ansible playbook. The Ansible playbook works well enough on its own but still requires us to already have a server setup for Ansible to execute the playbook on. What if we didn't need that pre-existing server and were able to on-the-fly provision one for our playbook? This arena is where Infrastructure-as-Code (IAC) initiatives really shine and where I would now like to introduce BitOps.

This is the second part in a StackStorm tutorial series:

• Part 1: DevOps Automation using StackStorm - Getting Started
• Part 2: DevOps Automation using StackStorm- Deploying with Ansible
• Part 3: DevOps Automation using StackStorm - Cloud Deployment via BitOps
• Part 4: DevOps Automation using StackStorm - BitOps Secrets Management

To complete this tutorial you will need:

• ansible
• A Linux server with basic internet connectivity

If you prefer skipping ahead to the final solution, the code created in this tutorial is on Github.

---

Event driven DevOps automation is a concept based around listening for desired events and then performing a task in response. There are a wide variety of applications for the event driven 'cause and effect' relationship in both personal and enterprise environments.

In the home, upon returning  from shopping when your cellphone is detected on the network, you may want your WiFi enabled lights to come on automatically to a desired brightness depending on the time of day.

In the office, when a crucial system's data store is reaching capacity we may want to send an alert and create a Jira ticket to track remediation.

The question remains, how, or what do we use to 'listen' for these events?

Enter, StackStorm.

BitOps works well with different deployment tools and today’s focus is on Terraform. By the end of this you will have used BitOps to create a prod and test AWS VPC.