From the course: DevOps Foundations: Your First Project

Your application, pre-DevOps

From the course: DevOps Foundations: Your First Project

Start my 1-month free trial

Your application, pre-DevOps

“

- [Narrator] Let's set the scene. Explore California, a fictitious travel planning company, is located in the heart of San Jose, California. Explore California's website, primarily used to connect explorers and adventurers with California's beautiful landscape and scenery, has over 100,000 unique visitors a month and orders placed through the website account for over 70% of their five billion dollar a year revenue. That is no easy feat. Changes to the website have been very painful for Explore California because they don't embrace devops. Any downtime experience by the website can result in users flocking to Explore Texas, their biggest competitor. So any changes made to production must be very carefully coordinated, largely through lots of paperwork and process. No one except production engineers are allowed to deploy changes into the production infrastructure which is a collection of Linux servers running in a co-located data center. Furthermore because production releases only happen once a month, much of the week leading up to the release is spent working on merge conflicts across hundreds of branches across many Git repositories. Changes to production need to pass through the development QA and UAT environments before they are considered ready for production. All of these environments are much smaller in size than production and because more engineers have direct SSH access into the servers within these environments many of them have been hacked about during releases to address hotfixes and other urgent needs. And because there are only four development servers for the 70 developers at Explore California many teams will spend a lot of time waiting on other teams to fix their stuff. And, "It worked in dev, not sure why it doesn't work "in prod," is on someone's top 10 list of most popular phrases at Explore California engineering. Despite this complexity, actual development at Explore California is a bit of a chore. Laptops issued to developers here run Windows 7 and obtaining a recent image of the operating system build used in a real environment is hard to do because it's under IT's control so most of the development libraries and tool chain differs heavily from what's in the upper environments, quote-unquote. Furthermore, since every developer has a different setup the differences between each other's environments can be quite stark as well. Developers can choose to run tests but they often won't since they take a long time and tend to pass locally but fail in dev anyway. This makes it quite difficult for QA since they are usually the ones that make sure all of the tests get run and created. Explore California realizes that this is painful. They want to ship features faster and more reliably. How can devops fix this?

Contents