This is the true story of seven tools, picked to live in a delivery pipeline, work together and have their KPIs measured, to find out what happens when software delivery stops being used in silos, and things start getting scaled.
This is The Real World: DevOps.
In many ways, enterprise software delivery is a lot like a reality show.
You have a crowded software delivery pipeline housing wildly different tools, each born from different walks of life, designed to achieve different goals.
Upon answering the casting call, the tools go through a heavy vetting process, and the ones that are selected get thrown into a strange environment, tasked with helping an organization achieve a common goal.
But as evidenced by years of reality TV, in a house full of strangers––each bringing with them their own agendas and baggage––the drama can unfold quickly.
Before we discuss how you can get these tools to leave their hard feelings in the confessional and work in harmony, let’s take a look at who we have in our DevOps cast.
Meet the Continuous Integration (CI) tool, the first arrival to the DevOps pad. Enabling developers to integrate code into a shared repository several times a day, CI helps teams detect problems early. CI acts like a perfect housemate for developers. But for release managers, product owners, auditors, and the less technical team members, the CI pipeline is incoherent––think cab ride back from the club.
Still, the non-technical software stakeholders depend on the status of the CI pipeline to do their jobs. So, developers get tasked with writing manual processes to connect the different pipelines and communicate status. This approach has proven to be extremely time-consuming, expensive, and frustrating for everyone.
Say hello to the Provisioning tool––the key to standardizing software installation and management on various infrastructure and environments. This tool automates infrastructure by creating and managing your environments, using scripts that you write.
A staple at any DevOps party, Provisioning is fine when there are only a few scripts to write and maintain. But once the party gets going and there are a few too many scripts in the mix, things can get sloppier than a housemate’s late-night phone call to an ex.
Shacking up in the next room is the Configuration tool. This tool is great for managing infrastructure and other components with scripts. But just like the Provisioning tool, things get ugly when you start to over indulge. Configuration scripts are complex and labor-intensive, don’t account for dependencies, don’t support advanced deployment patterns, and don’t provide automated rollback.
Simply put, your configuration tool “isn’t here to make friends.”
Who’s that sitting in the hot tub? Oh, it’s your Container Runtime tool. A Container Runtime tool makes it easier for DevOps teams to create, deploy, and run applications by using containers.
Sounds pretty good, right? Well, as your Containers invite more and more of their boys from home to the party, their interactions with the other housemates become increasingly difficult. In DevOps terms, that means more configurations, extensive scripting and maintenance, and a slew of new security considerations.
Yet another housemate that can turn a small, civil gathering into a hot mess, microservices enable apps to be built from simple, small components. But building a microservice application, with the variety of tools needed, is not easy.
A single microservice is relatively easy to develop and deploy. But when hundreds or thousands of microservices need to be deployed to make an application work, the screaming starts, and the drinks get thrown.
Next up, the IT Service Management (ITSM) tool. The ITSM tool is a bit of a software delivery outlier, helping to deliver and manage IT services to the teams within the delivery pipeline. But in helping to promote structure and control around your IT activities, ITSM can seem like a bit of a party pooper.
How can developers feel the freedom needed to increase velocity if they’re under the control and oversight of a rigid ITSM tool?
Late to the DevOps festivities is your Application Security tool. This is no surprise given that they got a last-minute invite, even though they’re the housemate that should have arrived first. After all, without a tool for checking your code, you could lose everything, from your customers’ trust to your intellectual property. So why then do teams often fail to give Security an early invite? Because Security is usually seen as the wet blanket of the house. They don’t like spontaneous parties or when the other roommates bring guests home without asking first, but they need to be involved early in the planning process in order for you to produce great software faster.
Time for a House Meeting
The fastest way to turn your software delivery environment into the chaos that surrounds the typical reality show is to litter it with ad-hoc scripting, manual tasks, and unsustainable processes. DevOps transformations at scale fail because enterprises implement tools to address specific needs while ignoring the impact on the application delivery pipeline as a whole.
If you want to do DevOps at scale, XebiaLabs provides the only platform that delivers comprehensive, end-to-end release orchestration and deployment automation that integrates all your DevOps tools without the need for ad-hoc scripting. Call a house meeting with the XebiaLabs DevOps Platform and:
- Connect CI tools to your CD pipeline for a complete view of all your release pipelines
- Integrate provisioning and configuration management tools into the software delivery process
- Scale up and standardize multi-container and hybrid deployments with ease
- Connect features in the development backlog to the change tickets in ITSM tools
- Bake governance and security into your software delivery process, and report on all release activities at the push of a button
- Connect All Your Pipelines for End-to-end Continuous Delivery
- XebiaLabs and Environment Provisioning
- Scale Container Deployments with Ease
- XebiaLabs for Microservices
- Connect CI/CD and ITSM for Better, Faster Software Delivery
- Bake Governance and Security into Your Software Delivery Process