GROW YOUR DEVOPS SKILLS

LEARN HOW TO GET STARTED WITH DEVOPS

Whether you are from a system admin or software developer background, or if you are a recent new graduate or have been in the industry for a while, this book will give you an overview of the DevOps industry and provide you with a practical guide about how to get started with a career in the DevOps domain.

What is Coverd in this book?

  • What do DevOps engineers really do?
  • Important skills that DevOps engineers should have.
  • Switching a career from software engineer to DevOps
  • A transition guide from system admin to DevOps engineer
  • The career path of a DevOps engineer.

….

James’s book helped me to understand the necessary skills needed as a DevOps engineer so that I could make a smart transition to the DevOps domain.

— Michael Boam, Software engineer

What is DevOps?

DevOps gave us an edge

“DevOps has helped us do very frequent releases, giving us an edge on time to market. We are now able to make daily product releases as opposed to 6-month releases, and push fixes to our customers in a span of a few hours.”

— Hamesh Chawla, VP of Engineering at Zephyr

DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative siloes. The promised benefits include increased trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.

At its essence, DevOps is a culture, a movement, a philosophy.

It’s a firm handshake between development and operations that emphasizes a shift in mindset, better collaboration, and tighter integration. It unites agile, continuous delivery, automation, and much more, to help development and operations teams be more efficient, innovate faster, and deliver higher value to businesses and customers.

History of DevOps

The DevOps movement started to coalesce some time between 2007 and 2008, when IT operations and software development communities got vocal about what they felt was a fatal level of dysfunction in the industry.

They railed against the traditional software development model, which called for those who write the code to be organizationally and functionally apart from those who deploy and support that code.

Developers and IT/Ops professionals had separate (and often competing) objectives, separate department leadership, separate key performance indicators by which they were judged, and often worked on separate floors or even separate buildings. The result was siloed teams concerned only with their own fiefdoms, long hours, botched releases, and unhappy customers.

Surely there’s a better way, they said. So the two communities got together and started talking – with people like Patrick Dubois, Gene Kim, and John Willis driving the conversation.

What began in online forums and local meet-ups is now a major theme in the software zeitgeist, which is probably what brought you here! You and your team are feeling the pain caused by siloed teams and broken lines of communication within your company.

You’re using agile methodologies for planning and development, but still struggling to get that code out the door without a bunch of drama. You’ve heard a few things about DevOps and the seemingly magical effect it can have on teams and think “I want some of that magic.”

The bad news is that DevOps isn’t magic, and transformations don’t happen overnight. The good news is that you don’t have to wait for upper management to roll out a large-scale initiative. By understanding the value of DevOps and making small, incremental changes, your team can embark on the DevOps journey right away. Let’s look at each of these benefits in detail.

GROW YOUR DEVOPS SKILLS

LEARN HOW TO GET STARTED WITH DEVOPS

Whether you are from a system admin or software developer background, or if you are a recent new graduate or have been in the industry for a while, this book will give you an overview of the DevOps industry and provide you with a practical guide about how to get started with a career in the DevOps domain.

I have been working as a system admin for more than 10 years and wanted to make a change in my career to become a DevOops engineer. Jame’s book lets me understand what system admin skills are transferable to DevOps environment and what skills I need to learn to make the shift. That’s a lot!

— Jonathan Yang, System admin

Automation

Investing in automation eliminates repetitive manual work, yields repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for teams who don’t have them in place already. And hey: what better reason for developers, testers, and operators to work together than building systems to benefit everyone?

Teams new to automation usually start with continuous delivery: the practice of running each code change through a gauntlet of automated tests, often facilitated by cloud-based infrastructure, then packaging up successful builds and promoting them up toward production using automated deploys. As you might guess, continuous delivery is not a quick and easy thing to set up, but the return on investment is well worth it.

Why? Computers execute tests more rigorously and faithfully than humans. These tests catch bugs and security flaws sooner, allowing developers to fix them more easily. And the automated deploys alert IT/Ops to server “drift” between environments, which reduces or eliminates surprises when it’s time to release.

Another of DevOps’ major contributions is the idea of “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. That same thinking can be extended to the infrastructure that hosts them, whether it lives in the cloud or on the company’s own network.

True, systems are always changing. But we can create a facade of immutability by using code for provisioning so that re-provisioning a compromised server becomes faster than repairing it – not to mention more reliable. It reduces risk, too. Both development and operations can incorporate new languages or technologies via the provisioning code, and share the updates with each other. Compatibility issues become immediately apparent, instead of manifesting in the middle of a release.

“Configuration as code” and “continuous delivery” aren’t the only types of automation seen in the DevOps world, but they’re worth special mention because they help break down the wall between development and operations. And when DevOps uses automated deploys to send thoroughly tested code to identically provisioned environments, “Works on my machine!” becomes irrelevant.

DevOps has evolved so that development owns more operations – and that’s how Chef works. We can’t just throw it over the wall anymore. Our engineers are responsible for QA, writing, and running their own tests to get the software out to customers.

— Julian Dunn, Product Manager at Chef