Benefits

Overview

In this page, few of the benefits of using DFD would be mentioned. The number of benefits keep growing with time and requirements i.e. more requirement team throws at us, more we feel - Good that we had data!!!

So the benefits are not limited to the below given list. For the below given benefits have been clearly recognized by the team. More implementation of DFD can bring out more benefits like these.

Self dependent team

In most of the cases, there is central DevOps team, doing the builds and deployments. But that basically defies the purpose of DevOps. DevOps must enable the team to do build and deployments in unsupervised manner, as per their need. For a moment let's not talk about security and deployment authorization, but if you want to handover the build and deploy controls to your team, do you think the way your current pipelines are designed are simple enough for, say, a test engineer to deploy the right service in QA environment?

Let's take example of what we have talked about so far. A simple difference between entering the Git URL of the microservice vs selecting the service name, makes a huge impact on ease of use. This is only possible if you have some way to map the service with Git URL and that is stored somewhere as data and you pipeline uses that data. This is the simplest example.

If you implement DFD, you will eventually notice that it can help you in big tasks like promotion and release management in big ways, only because you have a lot of data about everything about a build and deployment. And if you design things right, you can handover these activities to the team so that they move with very high speed, safely without needing you.

DFD builds the platform for making things simple enough so that the team itself an use the DevOps system. DFD would not make it simple in itself. You need to think how you can use DFD to make things simple. But not having DFD in place, will make you incapable of doing so.

Future ready

Again, DFD does not make things future ready. It makes it possible for you to be future ready. But its possibility entirely depends on how you have designed your pipelines using DFD. With the power of DFD, you can implement pipelines, which are mostly future ready. But no one can predict the future, but being DFD in place, even when a new requirement comes in, you would notice it is much easier to do now.

Adding a new environment is the case we have talked here as example. That might be the simplest use case. But let's take about another use case. Assume one fine day, your manager asks you to block the deployments in QA if the build is not from the development branch. Now while building we know which branch we are building it from. In the end of the build we get our deployable. So we actually have all the data we need to implement this restriction, but what we do not maintain is the relationship between what deployable got created from which branch. Not saying that you maintain this upfront but if you have data stored in the way mentioned about build and deployment., you can make your way out of this situation.

It is about having the data. Use of that data may come up in various way, in future. But just having that data makes you future ready.

Micro authorization

If you are Jenkins user, you must be knowing that Jenkins gives a good enough authorization control on pipelines. But if you need to give separate users access to deploy in a different environment, then you would end up creating pipelines per environment and give access accordingly. This is secure but we can do better than this.

With help of DFD, we can implement in-pipeline per feature authorization if design the pipeline and tasks well. We can go up to a level where different level of authorized users run the same pipeline with same parameters but get different output due to their roles or access rights.

It all depends on how you design it!

Tracking and history

This is the part where DFD looks exactly similar to Data Driven DevOps i.e. it is about the output data. If you capture output data thoroughly, you might end up being favorite of your project manager, development leads, test leads and quite a lot of people actually.

You can end up capturing a lot of DevOps metrices, which can be helpful in various ways e.g. application debugging, fault finder, trend analysis, easier advance feature development like code promotion, release management and a lot.

More you track, more visibility and control you get for future. Again, depends on how you have designed your data which is to be captured.