DevOps in Redmine

Everything you’ve always wanted to know about DevOps: origins, principles, use of methods, and implementation of DevOps in Redmine. .

The origins of the DevOps movement in the IT world date to around 2009. In brief, it is a methodology where development (Development, Dev) is tightly integrated with the process of using the product (Operations, Ops). DevOps is always changing, and it gives maximum flexibility because the product is updated over and over again up to hundreds of times a day. Developers are monitoring and analyzing user reactions, and then they write new requirement specifications for development. It is a process of continuous development and deployment.

Origins of DevOps

First, there was regular or “cascading” (waterfall) software development: a customer brings specific requirements to developers, who take them and “create” the products for a couple of months and then present the final product. Everybody believed that doing this was the right approach for work. Why invent anything else?

The hatchet was buried in the changes made to the expected final product. In theory, a “typical” product can be designed quickly. You just need to make an A4 sketch with some notes and proceed to the Development department without any additional questions about the process. In the received outcome, you do not need to make any changes to the product or perhaps just polish it a little bit here and there. If you need to update, change, or add something, it can be done quickly and without too much additional cost to the basic estimation.

In reality, however, most projects are complex. The customer or ordering party is often not 100 percent sure how everything should be done and what is the expected outcome. The analysts do their best to ask the right questions and understand the answers, but chances are high that no one really knows what the final product should look like and if it will be accepted at the end of the project. You can work on prototypes, mood boards, and sketches as long as you want, but only users can tell you how the product should work.

Then came a new stage in software development—a time for flexible Agile project management methodologies and approach.

All Agile processes are based on the principle of close and constant interaction between customers and developers. The sequence of actions: a client brings a list of requirements to developers, who break them into steps/tasks and organize them according to the priority for the final version of the product. The assignments are scheduled for one or two weeks called Sprints and executed. Then the developers close, perform, and coordinate with the customer a test version of the product, which is delivered within the scope of Sprint. When it is ready, they launch a new product to the market, check it, and correct errors. Then they push the process on the new circle over and over until all the objectives are met and the product is functioning properly.

A key feature of Scrum is the ability to run immediately, but customers usually don’t take advantage of this feature.

No problems should occur even if it is necessary to make changes during the work process. New functions could be added to the next round of tasks, and the team performs them.

If you see that the functionality of the test product receives negative feedback from users, it means it is time to reassess and make any necessary changes.

Here are the visible features of the new approach:

• Ability to manage changes and implement them immediately
• Capacity to test the project on real users rather than simulating the situation.

Everything is fine with this approach except a for significant problem without a solution. The barrier between clients and designers is finished, but the wall between developers and the IT department (testers and admins who are responsible for bringing the changes to life) is still there.

Again, we are entering a new stage. Welcome, DevOps!

What problem are solved by DevOps?

It is clear that functionalities are developed in “packages” even if the team is working on the Scrum. Then these “packages” are tested and finally deployed to a working product. So the product is developed in stages. When it is ready, we realize that Agile development becomes almost an analogy of waterfall methodology.

For a product that has already been launched in the market, there is a risk that if users do not approve and use one of the features from the Sprint, you shall change all the related functions. Everyone knows that it would be great to introduce a single functionality, check the reaction of users, and immediately decide what to do with all associated features. This way you can achieve almost 100 percent flexibility without unplanned extra work, right? DevOps is helping to solve the problem of unexpected changes, but it also resolves another problem of many IT companies—the barrier between developers and “IT people.”

Consider the following hidden conflicts:

• Developers prefer updates and changes. They get paid for it. An IT department likes a stable environment and a stable product, which involves less risk of something breaking.
• Developers work “strictly by the instructions.” IT tries to do the best for users.
• Developers work in their environment, while “IT guys” personalize the environment for testing purposes.
• Developers often do not have enough IT knowledge, while IT specialists do not know how to code.
• Developers and IT do not communicate with each other often enough. They are not aware of the issues and each department’s needs.

The problem actually has two sides. The first involves technology and processes, while the second involves human relations. The synthesis of these factors creates a particular mood within the team. You can often see that developers and testers/admins are the two fighting sides, which slows down product development.

How does DevOps help to solve the problem? With the following three fundamental principles:

• According to the methodology, it estimates the performance of the whole system rather than specific sections described by departments, developers, or administrators

An essential task for a manager who implements DevOps is to bring all participants to work as one team, with the primary goal being to increase product value for end users.

• Simple feedback system “right-to-left”

It indicates that the product is always evolving, and user reaction is monitored. As new challenges are discovered, they are followed by creating tasks and immediately pushed for development. This “pipeline” implies an appropriate level of process automation, test and deploy, and leads to open and frequent communication between employees.

The goal is to create a culture within the team that stimulates experimentation. We cannot always understand the level of product functionality that works as efficiently as possible without testing on its final customers. That is why it is important to ensure that each member of the team is aware that he/she can bring some valuable insight and take an active part in analyzing and designing its future development stages.

Does DevOps methodology work?

The principal question that always confronts developers who implement DevOps: Does the customer need such a process?

Everything depends on the size and complexity of your product or projectsas well as allocating resources. As a matter of fact, to be able to track all the processes associated with the project, you would have to only deal with it and nothing else. To improve work efficiency and improve delivery flow of new functionalities, a wide variety of methods are available. All have specific problems to be overcome before implementation, so the real question here is: is it better to work with or without them.

It is reasonable to apply some basic changes but not to move the mountain. We do not need to have a perfect process; we can just start with a few improvements to the process.

DevOps is a great approach for large projects, such as developing popular web services (it is used by Dropbox or Flickr) or complex IT projects systems, such as banking software. When we consider the continuous flow of improvements and fixes, we can assign separate resources for ongoing analysis and experimentation. It helps to plan and allocate resources for improving the product in advance. If your project is not that great, you can try to start with implementing flexible Agile technologies.

DevOps in Redmine

In describing the process of implementation of DevOps in Redmine, let’s focus on two elements: tools and methods.

As for the tools, we need to be able to coordinate our projects smoothly according to DevOps principles. To start, we need a CIS (Continues Integration Server) for checking all commits (changes) in the developed software. It helps to manage development and the deployment process. The best way to start would be with the Jenkins plugin, which is an open source automation server written in Java. It helps to integrate both testing and deployment procedures.

The core advantage of Redmine is that it helps to manage team communication, project management, along with the history of all the changes, comments, code commits, and all the other details necessary for a clear overview of development and the deployment process.

Integrated code commits are connected with tasks and projects. It means that all team members can see the full picture of current spring as well as an overview of the final release. It includes information regarding which changes have been completed, which modules of the software are involved, how they affect the other modules, and how everything is integrated with the remaining ones.

Then the commits are sent to the repository. It isn’t related to issues, and you can see commit status integrated with issues, which means that you can quickly see what’s been done and the current status of each part of the software that is being delivered. It provides a good understanding, for example, of the issues with status Done that are already finished in the development cycle and can be passed further. Adding status “Solved” means that issues also pass the testing stage successfully and can be released by the IT team.

Methods describes the organization of work and processes inside Redmine. To fully control DevOps, the manager needs to be able to see all tasks that should be developed and the ones that that have already been delivered and need to be tested on real users. For example, we solved this in our company by using two separated dedicated Agile boards: one for development and one for deployment. Each board is divided into stages appropriate for each part of the project, so Dev Board covers new tasks, ones in progress and finished, and those that are ready for testing. Deploy covers issues that are already available for testing (with a division for substages) and documentation (also with division). You also need to take care of constant communication between the two camps and constantly push for progress and improving the product.

In our example, DevOps helps in delivering many changes in a shorter time and with more proven changes that closely correspond with plans and initial needs.

For further reading

To read more about DevOps, I recommend lecture of The Phoenix Project: a novel about it, DevOps, and helping your business win written by Gene Kim, Kevin Behr, and George Spafford.

Have any readers implemented DevOps in your teams and can share the experience? I would love to hear your stories and opinions.