Open Source BitOps: v2.1-2.3 Updates

It’s been a while since BitOps v2.0.0 introduced extensibility via plugins and a core platform rewrite with Python. Since then, we’ve been working hard—experimenting and gathering feedback, exploring the project's future, adding new features, fixing bugs, and improving the tool.

Here are the main highlights for the most recent BitOps releases: v2.1, v2.2, v2.3, and plans for future development.

 

What is BitOps, anyway?

BitOps is an open-source tool developed by the Bitovi DevOps team based on client use cases deploying infrastructure and apps in a repeatable manner.

The project was created to simplify deployment operations and reduce the time teams need to create new projects and onboard developers by using repeatable automation practices, templates, and structure across the projects. It’s like bootstrap but for the infrastructure.

BitOps gets you up and running with the best DevOps practices like infrastructure as code and containerization. It encourages 12-factor app principles and continuous deployment, allowing you to keep the development clean and organized between the different environments. BitOps integrates with DevOps tools like Ansible, Helm, Terraform, AWS, and others, saving time so you can focus on what’s more important - app development.

BitOps v2.1

This version comes with over 15 changes, enhancements, and fixes. The most notable in v2.1.0:

bitops.sh

The BitOps project has found a new home at its own domain name: bitops.sh. It hosts the documentation at this moment and will become a full-fledged website in the future.

BitOps Image: Latest Plugin Versions

In the past, the plugin versions were statically pinned in the BitOps image. Based on community request #307, we started packaging the latest available plugin versions for the current BitOps-released image.

Bi-weekly Community Meetings

Outside of Slack and GitHub, we’ve started gathering every two weeks to discuss the ongoing project development and ideas, features and implementations, problems and bugs, what works and what doesn’t, and what we want to do next.

Every meeting has an agenda and minutes for the community to understand the project direction. We’ve had eight meetings, with fun sessions like brainstorming, pair programming, demos, roadmap planning, and voting on future functionality. We’re looking forward to collaborating more!

Check out the Previous BitOps Meetings, and we invite everyone to join to share your use case or perhaps discuss a feature request that’s missing in BitOps so far.

Roadmap

Together with the core BitOps team, we defined the Development and Product roadmaps. The development roadmap page includes the backlog (what we want to do), and what was already done between the major features. Outside of a more granular release changelog, this brings a high-level helicopter view of the plans and direction we’re taking with the deployment automation.

Check out the BitOps Roadmap page, and feel free to propose a feature request!

Coding Standards

As Henry Ford said:

Anyone can have their own [python code style], as long as it’s [re-formatted with] black.

And so we adopted black, the uncompromising code formatting tool supported by the Python Foundation for enforcing the common code styles for the Python codebase. So if you’d like to join the open-source development and submit a PR - we follow the industry standards.

BitOps v2.2

With more than 20 enhancements and fixes, v2.2.0 introduces additional breaking changes, so please refer to the migration guide. Other highlights:

Bug Fixes

The release accumulates many bug fixes and improves situations with the corner cases around naming, logging, environment variables, plugins, error reporting, and schema.

Real-time output streaming

It’s just something that should always be there and was fixed in v2.2.0:

Code Quality

We’ve added a python static code analyzer like pylint which helps us to follow the common best practices and standards across the python codebase. This is just an entry point for the automated testing improvements, including unit, end-to-end, and integration testing for the BitOps core and plugins. All will help maintain the tool’s stability.

With code review annotations in the BitOps repository, CI errors coming from the linting tools appear as review notes, so there is no need to look at the CI logs!

BitOps v2.3

Release with more than ten changes comes with many fixes around handling the correct exit codes in the plugins. Other major changes:

Secrets Masking

With v2.3.0, you can mask the secrets via bitops.config.yaml:

# Define the secrets to mask
masks:
  - # regex to search
    # looks for `BITOPS_KUBECONFIG_BASE64={string}`
    search: (.*BITOPS_KUBECONFIG_BASE64.*\=)(.*\n)
    # replace the value part
    replace: '\1*******\n'

This new feature allows you to remove or mask sensitive strings from the BitOps output and logs.

Local Plugin Install

Previously it was possible to install the BitOps plugin from the git repository. With the new feature, it’s also possible to install the plugin locally via file:///plugin-dir/. It makes the development and automated plugin testing easier. Besides that, check out the newly reworked development documentation for creating a new plugin.

GitHub Actions

We started using BitOps as a base building block for the GitHub Actions. Check out the Deploy Docker to AWS (EC2) Action in the GitHub Marketplace, which allows publishing a docker-compose app to an AWS EC2 instance. It uses Terraform to automate the creation of Route53 record, Load Balancer, AWS EC2 Instance, Security Groups, and Ansible for preparing the VM and ensuring the actual Docker deployment worked.

There are a lot of moving pieces, and BitOps automates them for you, so it’s a seamless developer experience!

What’s next?

• Documentation, Landing page, Website

  • We identified many improvements in how we could describe BitOps and show the value behind the tool. The documentation has become one of our priorities, and we’ll continue improving how we position BitOps in front of the community, including the communication channels.

• GitHub Actions

  • Deploy Docker to AWS (EC2) GitHub Actions is a great example of hiding the deployment operational complexity allowing you to focus on more important things.We’re working hard to provide it with the BitOps project, and we plan to add more automations for different projects and compose them into a discoverable catalog, so stay tuned!

• Tool Quality

  • As we progress from MVP to a complete product, there’s increasingly more need for quality, consistency, and ease of use. Functionality and user flow, automated testing and CI/CD, coding standards, schema validation, error reporting, and best development practices will help us to improve the overall tool quality and development velocity allowing us to prototype without compromising on stability. We want the best experience for you!

• Bitops-CLI

  • CLI is the first point of interaction someone is having meeting BitOps. We decided to go with the dedicated Golang tool as a future of the BitOps Operations Repository generator. Golang provides the best portability with a single binary and we’re looking forward to bringing it to our users.

Many more features are lined up, like Improved Terraform PR flow, Ops repo catalog, Deployment sub-steps, support for Private plugins, or Operations repo composability, which allows you to tie together different configurations as building blocks for bigger infrastructure projects.

Check out our Roadmap! We’re looking forward to collaborating with everyone during this project’s early stages of development. So try BitOps, and let us know what difficulties you’re facing while deploying applications or what features you’d like to see, and let’s build together.

You can join us on Discord, in Community Meetings, or give the bitovi/bitops project a ⭐ star on GitHub.

Never miss an update!

Subscribe to the blog 📬