Love DevOps? We're hiring!
FP Complete's DevOps Homepage
DevOps is a broad term covering many different topics, including tooling, team structure, and even project management. There is certainly some debate in the world as to what constitutes "real DevOps." At its core, DevOps is about one core goal: knocking down the wall between software development and systems operation.
You've been working on a new network service for the past six months. It uses a database, stores some files uploaded by users, and makes some external requests. It's accessible over HTTP. You've tested it extensively, both with a full integration test suite and manual testing with your Quality Assurance team. The big launch date is approaching. You tag a commit in your team's Git repository, and notify your operations (ops) team that it's ready to ship.
Then, as is wont to happen, all hell breaks loose.
Ops can't build the software. You spend the weekend answering Slack questions about which build tools to install, system level dependencies, etc. After a week of misery, there's a production-ready executable. Frustrated with each other, the ops and dev teams silently agree to skip repeating the process for the test suite.
Ops deploys to a production cluster... and the app doesn't work. Dev has to come in to help debug, but they don't know how to access the log files. So there's a lot of late-night requests for the ops team to grab logs and send them over. Two days later, the dev team realizes that the database has been misconfigured.
The next two months are spent fixing minor issues that should have been caught by the test suite, and only appear in production due to minor differences in the dev versus production environment.
The next release ends up pushed back by two months due to all the unanticipated work. And then this process starts all over again.
How to fix it?
If this story sounds all too familiar to you, you're not alone. This is how much of the software development world has operated historically, and many continue in these practices today. The DevOps methodology is about systematically addressing the root causes to this with better tooling and better processes.
The first step to adopting DevOps and escaping this mess is: knock down the walls between dev and ops. The ops team should not be a separate team called in at the last minute. Instead, DevOps engineers have a deep understanding of both software development and operations, and should be intimately involved from the beginning of a project with:
- Advising on architectural design issues
- Setting up a reproducible local dev environment
- Designing a test automation system which will mirror production
- Configuring a Continuous Integration system
- Defining a set of scripts for deploying a staging environment
By taking these steps at the beginning of your development cycle, you avoid nasty surprises from popping up when you're ready to deploy. You make it easier and faster to make changes. And while it may slow down the initial start to a project by a bit, those costs are quickly amortized out with the productivity gains felt by your entire team.
The DevOps world is relatively young, and its tooling continues to evolve quickly. FP Complete provides an online DevOps syllabus and offers commercial training services to get you and your team up to speed quickly.
For a deeper dive into individual tooling topics, please see some related pages:
- Continuous Integration and Deployment
- Logging, monitoring, and alerting
- Declarative infrastructure
Who DevOps is for?
- Want to know how to organize your engineers around DevOps? Read about DevOps team structure.
- Does DevOps require the cloud? Can you use it for on-prem deployments? Read about DevOps and the cloud
- Learn more about FP Complete's mission
Love DevOps? We're hiring!