Probo is a new tool for automating testing and quality assurance during web application development. It is based on a core idea that a team should deploy features quickly, and with no negative impact on an already functioning system. The people driving the request must be part of the process from the beginning. Bringing stakeholders together helps ensure the success of a project and is part of the core mission of DevOps.
Before we explain how Probo CI goes a long way to fulfill the promise of DevOps harmony, let’s begin by looking at the definition of DevOps to understand where Probo fits in.
Development vs. Operations
The idea of DevOps is really a return to the fundamentals of computer programming and development. The early pioneers of computing didn’t differentiate between applications and network internals; they wrote programs, ran servers and figured out how to make everything function in harmony.
As the software industry grew, corporate structure followed. Companies with no previous experience entered the field of software development. As new departments were established to create software, older divisions like IT suddenly became tasked with supporting the needs of software development teams in addition to keeping corporate email servers and backup systems running. Things only got worse when software teams started making web applications.
At that point, the internal infrastructure of the company was being used to run programs that had higher volatility and allowed public access to company assets. You can see how these departments might start to have opposing goals. The worst cases ended up with an ecosystem that included Development and IT operations.
Development is in charge of shipping things quickly and rolling out new features; operations is responsible for making sure nothing ever goes down. The two divisions have contrary goals, maybe even separate budgets, and they’re judged on separate criteria.
For development, the criterion is new features brought to market. The dev team is asked, “How fast are we able to roll out new features for our customers or employees?” For operations, on the other hand, the primary criterion is keeping systems up and running. “How many nines do we have in our uptime?” Each 9 gets a lot harder. If you’re going for 99% of the time, you can be down for days every year. Then you go a couple of orders of magnitude to 99.99%, and you really don’t have a lot of room for broken systems.
DevOps: Development Plus Operations!
The idea with DevOps is to break that imposed structure and combine the teams. DevOps seeks to end the mandate that developers don’t do operations, and operations people don’t do development. Rather, it makes business sense to give operations people some development resources and permission to write development tools, and give developers some of the responsibility for keeping things up.
The rationale is responsibility across departments. If developers are the ones carrying pagers and getting woken up in the middle of the night if something goes down, they’re going to be a little more hesitant to push code through without sufficient review and quality assurance steps.
DevOps Shifts Priorities
When a company combines two departments and two sets of budgets into one integrated cross-functional team that’s responsible for meeting business priorities, some unexpected and welcome efficiencies emerge.
If a team assumes it has to roll out new features and updates regularly, not once a year, not once a quarter, but every week, the group begins to look more at how changes won’t cause down time. Maybe they stop talking about the goal of having no down time, and instead start talking about how quickly they can recover from downtime, or how to prevent it in the first place.
Culture, Automation, Measurement and Sharing
Probo fits into the DevOps world because it helps cross functional teams collaborate on a workflow in progress. In DevOps, the rallying cry is CAMS: Culture, Automation, Measurement and Sharing. Right out of the gate, Probo helps you with automation, sharing, and measurement, and once it’s part of the daily workflow, Probo promotes a culture of inclusion.
Probo automates all of your builds from the time you push each and every change. Pull requests on Github, Bitbucket, or Stash automatically trigger a Probo build of the project and provide a link to a working version of the application at that specific commit. This isn’t a headless environment for running integration tests, though Probo does that as well. This is a fully functional web app that is usable and can be viewed by any members of your team or QA staff. This is a live working site build from a specific feature change. The entire build process is automated and configurable. The configuration lives in code, so your entire build process is reproducible.
Since your PR triggers a working build, it allows you to do what you’re working on with the rest of your team, or with the marketing team, or with a QA tester, or the editorial staff. Just the way that open source software aims to achieve high quality by allowing others to view and contribute to the code, Probo aims to achieve quality by letting people aside from developers interact with new features. This greatly reduces the chances that you’ll have to make hotfixes after a launch since most of the people who care will already have verified that the feature meets its goal.
When your teams can communicate and work together it fosters a culture of ownership over the product and it makes the development process less of a black box for non-technical staff. Communication and respect for the project foster a healthier and more productive company while saving time and money.
This post originally appeared on the Probo blog.