Practical DevOps

Implement DevOps in your organization by effectively building, deploying, testing, and monitoring code, 2nd Edition

Joakim Verona

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788398619
• Edition: 2
• Topic: Informatica
• Subtopic: Elaborazione di dati su cloud

Understand the benefits of DevOps and continuous delivery and see how they support the agile software development processAbout This Book• Learn how DevOps can accelerate your entire software development life cycle• Improve your organization's performance to ensure the smooth production of software and services• Get hands-on experience in using efficient DevOps tools to better effectWho This Book Is ForIf you're a developer or system administrator looking to take on larger responsibilities and understand how the infrastructure that builds today's enterprises works, this is the book for you. This book will also help you greatly if you're an operations worker who would like to better support developers. You do not need any previous knowledge of DevOps to understand the concepts in this book.What You Will Learn• Understand how all deployment systems fit together to form a larger system• Set up and familiarize yourself with all the tools you need to be efficient with DevOps• Design an application suitable for continuous deployment systems with DevOps in mind• Store and manage your code effectively using Git, Gerrit, Gitlab, and more• Configure a job to build a sample CRUD application• Test your code using automated regression testing with Jenkins Selenium• Deploy your code using tools such as Puppet, Ansible, Palletops, Chef, and VagrantIn DetailDevOps is a practical field that focuses on delivering business value as efficiently as possible. DevOps encompasses all code workflows from testing environments to production environments. It stresses cooperation between different roles, and how they can work together more closely, as the roots of the word imply—Development and Operations.Practical DevOps begins with a quick refresher on DevOps and continuous delivery and quickly moves on to show you how DevOps affects software architectures. You'll create a sample enterprise Java application that you''ll continue to work with through the remaining chapters. Following this, you will explore various code storage and build server options. You will then learn how to test your code with a few tools and deploy your test successfully. In addition to this, you will also see how to monitor code for any anomalies and make sure that it runs as expected. Finally, you will discover how to handle logs and keep track of the issues that affect different processes.By the end of the book, you will be familiar with all the tools needed to deploy, integrate, and deliver efficiently with DevOps.Style and approachThis book is primarily a technical guide to DevOps with practical examples suitable for people who like to learn by implementing concrete working code.

Issue Tracking

In the previous chapter, Chapter 8, Monitoring the Code, we looked at how we can keep an eye on our deployed code with monitoring and log-handling solutions.

In this chapter, we will look at systems that handle development workflows within an organization, such as issue tracking software. Such systems are an important aid while implementing Agile processes.

What are issue trackers used for?

From an Agile process standpoint, issue trackers are used to help with the minutiae and details of the Agile process. The entities handled by the issue tracker might represent work items, bugs, and issues. Most Agile processes include an idea of how to manage tasks that an Agile team are to perform, in the form of post-it notes on a board or an electronic equivalent.

When working in an Agile setting, it is common to have a board with issues on handwritten post-it notes. This is a central concept in the Kanban method, since Kanban actually means signboard in Japanese. The board gives a nice overview of the work in progress and is pretty easy to manage because you just move the post-it notes around on the board to represent state changes in the workflow.

It is also pretty easy to change your Kanban board by just rewriting the various markers, such as lanes, that you have written on your board. The following is a photograph of a physical board. There are a lot of details present in the photo, which you can safely ignore. Figuring out which labels to use on your team's board is part of the process of using a Kanban board. Thus Kanban boards belonging to different teams rarely look the same:

Physical boards are also common with Scrum teams.

On the other hand, computerized issue trackers, which are mostly web based, offer much better detail and can be used when working remotely. These issue trackers also help you remember steps in your process, among other benefits.

Ideally, one would like both a physical board and an issue tracker, but it is a lot of work to keep them synchronized. There is no easy way to solve this basic contention. Some people use a projector to show the issue tracker as if it was a board, but it does not have the same tactile feel to it, and gathering around a projected image or monitor is not the same thing as gathering around a physical board. Boards also have the advantage of being always available and convenient for reference when team members want to discuss tasks.

Technically, issue trackers are usually implemented as databases of objects representing state machines, with various degrees of sophistication. You create an issue with a web interface or by other means, such as email or automation. Then, the issue goes through various states due to human interaction, and, in the end, the issue is archived in a closed state for future reference. Sometimes, the flow progresses due to an interaction from another system. A simple example might be that a task is no longer deemed valid because it is overdue and is automatically closed.

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 counter-intuitive 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, the only extra metadata is the reporter, and you could probably remove that as well and the tracker would still be functional. With a post-it note, you handle open and closed states simply by putting the post-it on the board or removing it.

When project managers first encounter an electronic issue tracker, there is often a tendency to go completely overboard with adding complexity to the state machines and attribute storage of the tracker. That said, there is clearly a lot of useful information that can be added to an issue tracker without overdoing it.

Apart from the previously mentioned basic information, these additional attributes are usually quite useful:

• Due date: The date on which the issue is expected to be resolved.
• Milestone: A milestone is a way to group issues together in useful work packages that are larger than a single issue. A milestone can represent the output from a Scrum Sprint, for example. A milestone usually also has a due date, and if you use the milestone feature, the due dates on individual issues are normally not used.
• Attachments: It might be convenient to be able to attach screenshots and documents to an issue, which might be useful for the developer working on the issue or the tester verifying it.
• Work estimates: It can be useful to have an estimate of the expected work expenditure required to resolve the issue. This can be used for planning purposes. Likewise, a field with the actual time spent on the issue can also be useful for various calculations. On the other hand, it is always tricky to do estimates, and, in the end, it might be more trouble than it's worth. Many teams do quite well without this type of information in their issue tracker.

The following are also some useful states that can be used to model an Agile workflow better than the plain open and closed states. The open and closed states are repeated here for clarity:

1. Open: The issue is reported, and no one is working on it as of yet.
2. In progress: Somebody is assigned to the issue and working on resolving it.
3. Ready for test: The issue is completed and is now ready for verification. It is unassigned again.
4. Testing: Someone is assigned to work on testing the implementation of the issue.
5. Done: The task is marked as ready and unassigned once more. The done state is used to mark issues to keep track of them until the end of a Sprint; for example, if the team is working with the Scrum method.
6. Closed: The issue is no longer monitored, but it is still kept around for reference.

In the best case scenario, issues progress from one state to the next in an orderly fashion. In a more realistic scenario, there is a likelihood that a task goes from testing to open instead of done, since testing might reveal that the issue wasn't really properly fixed.

What do we need from an issue tracker?

What do we need from an issue tracker apart from it supporting the basic workflows described previously? There are many concerns, some of them not immediately apparent. Some things to consider are listed as follows:

• What scale do we need? Most tools work well on scales of up to about 20 people, but beyond that we need to consider performance and licensing requirements. How many issues do we need to be able to track? ...