Book Image

Practical DevOps

By : joakim verona
Book Image

Practical DevOps

By: joakim verona

Overview of this book

DevOps is a practical field that focuses on delivering business value as efficiently as possible. DevOps encompasses all the flows from code through testing environments to production environments. It stresses the cooperation between different roles, and how they can work together more closely, as the roots of the word imply—Development and Operations. After a quick refresher to DevOps and continuous delivery, we quickly move on to looking at how DevOps affects architecture. You'll create a sample enterprise Java application that you’ll continue to work with through the remaining chapters. Following this, we explore various code storage and build server options. You will then learn how to perform code testing with a few tools and deploy your test successfully. Next, you will learn how to monitor code for any anomalies and make sure it’s running properly. Finally, you will discover how to handle logs and keep track of the issues that affect processes
Table of Contents (17 chapters)
Practical DevOps
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Introducing software architecture


We will discuss how DevOps affects the architecture of our applications rather than the architecture of software deployment systems, which we discuss elsewhere in the book.

Often while discussing software architecture, we think of the non-functional requirements of our software. By non-functional requirements, we mean different characteristics of the software rather than the requirements on particular behaviors.

A functional requirement could be that our system should be able to deal with credit card transactions. A non-functional requirement could be that the system should be able to manage several such credit cards transactions per second.

Here are two of the non-functional requirements that DevOps and Continuous Delivery place on software architecture:

  • We need to be able to deploy small changes often

  • We need to be able to have great confidence in the quality of our changes

The normal case should be that we are able to deploy small changes all the way from developers...