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

Some examples of workflows and issues


Although the term "issue" is used throughout this chapter, some systems use the terms "ticket" or "bug". Technically, they are the same thing. An issue might also represent a to-do item, enhancement request, or any other type of work item. It might feel slightly counterintuitive that, technically, an enhancement is basically the same thing as a bug, but if you see the enhancement as a missing feature, it starts to make sense.

An issue has various metadata associated with it, depending on what it represents and what the issue tracker supports. The most basic type of issue is very simple, yet useful. It has the following basic attributes:

  • Description: This is a free-form textual description of the issue

  • Reporter: This represents the person who opened the issue

  • Assigned: This is the person who should work on the item.

Also, it has two states: open and closed.

This is usually the minimum that an issue tracker provides. If you compare this with a Post-it note...