Posts Tagged :


Maybe you are still doing Dev & Ops? Check whether you are on the right DevOps journey

Businesses are failing to put DevOps into practice.As per a report by 2nd Watch 2018 on DevOps, almost 78% of the respondents stated that they have different teams for managing infrastructure/operations and development and 38% of the respondents say that they are managing infrastructure manually. This shows businesses are halfway in their DevOps journey and are wondering why they are not able to make most out of it. They are still looking for answers to questions like –

  • How have we again missed the deadline for release? We are already having a DevOps team.
  • Why there are a mismatch between developers build and product managers plans for what to include in the build?
  • Why there’s still downtime and wait times?
  • Why we are still having irregular releases with operational constraints?
  • Why we are still depending on infra teams for the provisioning of environments?

If you are also looking for answers to similar questions, it’s time to realize that DevOps is not tools, technology or teams. It is a change in the way teams work to achieve Continuous Delivery automating build and testing with parallel monitoring and continuous feedback in place to ‘fail fast and fix fast’.

DevOps is no more a buzzword, but businesses are having a hard time finding the right way of adopting DevOps. DevOps is percolating in the software development lifecycle is at a rapid pace because emerging technologies need a new development lifecycle. The product and software innovation in trending technologies such as Mobile, Big Data, Cloud, Social, IoT, AI, and ML requires the need for agility and dynamism. The main reason faster adoption of DevOps is the consumerization of tools and technologies that drive the need for higher quality and faster delivery.

Let’s have a look into why Dev & Ops working in silos is not good for emerging technologies and what are the changes need to be done to move into a more collaborative culture of DevOps.

Dev & Ops – Two different teams incentivized differently

In traditional development, development teams are always encouraged to embrace change while the operations team are encouraged for creating a more stable environment, thus resisting change. Developers love change, delivery, and speed of releases whereas the operation teams look at being more consistent, the application being stable and available always. The problem arises as Dev and Ops working in different environments create a disconnected team, information, and perspective. The goal for both the teams is to achieve better business productivity.

Getting best out of Dev & Ops: DevOps

DevOps is an enabler of continuous delivery that ensures both quality and speed for the applications that are made available to the end-user. Continuous delivery changes the business model by shifting the operational constraints to decide application releases to business readiness to application releases, upgrades, products, features etc. with high quality, without compromising the brand value. This change in business model ensures that you are getting best out of DevOps.

The first thing is in implementing DevOps is to automate the delivery and deployment pipeline to create a feedback loop whenever the code is shipped to production. The key to achieving this is by automating the continuous delivery pipeline with feedback provided directly to the developer to fix bugs if any.

Second thing, your CD pipeline should be able to measure business outcomes as well as outputs. Faster deployments, achieving deadlines, eliminating downtimes are all outputs but there are significant outcomes such as customer retention, customer renewals, satisfaction rates etc. that reassures that your DevOps journey is pointed in the right direction.

What we do at Qentelli –

At Qentelli, our core focus has been achieving Continuous Delivery for high performance, high velocity agile teams. We classify the phases broadly to achieving CD broadly as:

  1. Continuous Planning and Development: Leverage engineering best practices and adopt a test first approach such as – TDD and bring in early testing like Unit Test Automation
  2. Continuous Testing: To integrate QE/SDET integration test first utilizing BDD frameworks and approaches that tie in user stories and features directly to the methods as they get developed, and early functional and automated unit testing
  3. Continuous Integration: Leverage automated trigger of unit and functional tests for every build /check in.
  4. Continuous Build: Adopt build tools such as Maven for creating, building, publishing and managing dependencies during development phase to reduce time and effort
  5. Continuous Deployment: Build a continuous deployment framework with DevOps tools, Test again Certify the build and move to higher environments
  6. Continuous Monitoring and Measurement: Real User Monitoring is a start. Metrics across lifecycle and traceability are a mandate
  7. Continuous Feedback: Testing in Prod (Functional), Real User Experience measurement and synthetic monitoring that enable a direct Feedback loop to dev / plan phase

To learn and explore more in detail about Qentelli’s AI-driven DevOps implementations, please write to us at Our experts will be delighted to engage with you. Also, you can visit Qentelli’s social links for more details – Facebook Twitter LinkedIn

About Qentelli

Headquartered in Dallas, TX with global delivery teams in India, Qentelli is an Industry Thought Leader in Quality Engineering, Automated Testing and Continuous Delivery. With high performing engineering teams working in the dedicated Innovation Group, Qentelli brings design thinking to address complex business problems and enables Continuous Delivery across Enterprise IT through automation for its global customers.

Unsuccessful DevOps Implementation? – Create actionable insights for Successful DevOps journey with Quality Intelligence
Why Organizations fail with their DevOps?

Quality and Speed are the two most important outcomes of a successful DevOps journey. Be it an organization just taking baby steps towards the journey or an enterprise with most advanced CI-CD implementation, improving their product quality and delivery speed is a constant endeavor. Your organization has a failed DevOps implementation if you were not able to achieve any significant improvement in Quality and Speed! DevOps failure is not uncommon and even most mature organizations fail at it in the first go. There’s no secret recipe or ingredient to get DevOps right but, if you want to succeed, read on, on how you can put your journey back on track.

Getting to Quality and Speed

Quality and Speed are the result of continuous improvement and learning. For continuous improvement, organizations need to derive insights and learn from their data.

Data can come from various data sources, both structured and unstructured, real-time and historical. The key to deriving insights is collecting the data from the various processes, tools, servers, resources in your journey. Right from your collaboration and planning tools to your test logs, build logs, application monitoring logs and support tickets, everything needs to be collected. The data thus collected, can then be leveraged and insights can be built to help improve processes.

Insights and Intelligence

So how do you create Insights and intelligence from data? Metrics and KPIs are a good start, but are limited in providing enough insights to take corrective actions. Being able to combine various key KPIs is important to derive insights. For example, one of the most important metric in DevOps, MTTR (Mean Time To Recovery), can give you understanding of where you stand currently, but unless you have the ability to gain insights into which processes would help you reduce the MTTR value, it will be difficult to continuously improve. A Quality Intelligence platform helps to connect various data points and KPIs to derive the insights. As in the example of MTTR, the most important processor data point to improve would be incident detection. If you take more time to detect, the time to recovery will increase. Connecting these two key KPIs helps provide actionable insights for improvement.

As you start deriving insights from your data and metrics, the next step of improvement is to derive intelligence, which can then help predict incidents before they occur and in few cases use the intelligence for auto-healing.

Easier said than done. We, at, Qentelli understand the importance of deriving intelligence from business data and metrics and tying them to KPIs to give businesses a complete picture of where they stand in their DevOps journey. Qentelli has developed its own intelligence platform to help businesses adopt continuous delivery and DevOps without failed attempts.

Qentelli’s TED as Quality Intelligence Platform

Qentelli created TED, an Engineering dashboard with capabilities to collect data from various data sources, create metrics and define KPIs and derive insights for improvement. What makes TED a true Quality Intelligence platform and unique, is its ability to derive actionable insights for most key DevOps KPIs out of the box and artificial intelligence (AI) to improve processes, provide predictions for incidents and auto-healing for broken processes. Qentelli helped some of Fortune 1000 companies get better with their Quality and Speed using TED.

To learn and explore more in detail, please write to us at Our experts will be delighted to engage with you. Also, you can visit Qentelli’s social links for more details-
Facebook Twitter LinkedIn

About Qentelli

Headquartered in Dallas, TX with global delivery teams in India, Qentelli is an Industry Thought Leader in Quality Engineering, Automated Testing, and Continuous Delivery. With high performing engineering teams working in the dedicated Innovation Group, Qentelli brings design thinking to address complex business problems and enables Continuous Delivery across Enterprise IT through automation for its global customers.

Qentelli, A Continuous Delivery Company!

About a year ago, we had finished off our new year 16 blog with a promise to Simplify Complex and Innovate in Software Engineering. The year 2016 saw just that happen at Qentelli. Oh, what a year it was!

6 Patents, 8 Unique products that simplified over a dozen complex, critical issues through well crafted and engineered solutions comprising a little over 50,000 lines of code, powered by 8000 mugs of coffee.

We (more than) doubled our service delivery team and quadrupled our innovation team for additional horsepower for that engine to run on turbo mode. Trust me, we couldn’t have asked for a better team. It is one big happy family. Oh and we topped the year off with couple of interviews with a leading industry analysts on Artificial Intelligence (AI) and CT.

AI – it has been close to our hearts at Qentelli. It is something that excites a great deal by the sheer potential it brings. We will formally launch a tool built on Machine learning, deep learning and adaptive intelligence for automated remediation within the DevOps CD value chain. This is something that is going to change the way continuous testing, monitoring and feedback happen in the CD world. Watch for more!

Oh Yes! We Did!

January is going to be filled with exciting stuff from us , beginning with Product Launches, additions to our over growing team and a whole lot more.

Here’s to the promise of another exciting year in engineering innovation and the Qentelli Way!

Watch for more!

Are the Contextual Cousins (DevOps and Continuous Delivery) in your FY17 Budget?

The Holiday season is a great time for family and friends; I am spending this special time this year with my family – The Qentelli team and specially the innovation group. Let me tell you, we have some very cool stuff on the way! You folks are going to love what you see.

I cannot help but notice, this is “that” time of the year. Resolutions, resolutions, resolutions!! A lot of positivity and souls determined to make a change are in the air this time of the year, specially in people’s personal lives. Things have come to a grinding halt at most enterprises, some due to forced shut downs and others just too happy to work. Further still, there are all those enterprises management / leadership teams that can only think of their versions for budget and forecasting for the year 2017.

The title of this post says Contextual Cousins – Continuous Delivery (CD) and DevOps. What I mean by it? Let me explain.

To many, they are different terms. To me (and us at Qentelli) they may be different terms but their goals and what they recommended make them so similar that appear to be from the same lineage; hence I call them Cousins. In my earlier posts on DevOps and CD I outlined the core elements of both. How do I mean? Here is a quick recap.

DevOps Vs. CD

The resemblance of lineage is so uncanny; I cannot resist calling them cousins.

Why must these Cousins be in your 2017 budget?

  1. All those missed deadlines can be so 2016: happy hours don’t have to be missed
  2. Quality – Production defects, Releases put off due to defects; lesser time to Market can be curbed
  3. Eliminate of Wait times
  4. Eliminate of downtimes
  5. Silo’d team / minimal Collaboration can be a thing of the past
  6. DevOps as a toolset can rest in peace
  7. CI is limited to Unit Testing/Build Validations can be put to bed
  8. Performance Testing an after thought or occurring too late can be left behind
  9. Production feedback being reactive/ issue based / transaction based can end now!

Besides all of these points, Transformation initiatives are great to kick things off in the New Year when the energy is high, people are more open to change.

If these reasons don’t motivate you, it could be due to one of the two: CD is not in your immediate agenda or you believe (Still) in tooth fairies.

So, here’s the deal to simply put it. Adopt these practices and life would be simpler (better I might say, with concrete evidence, if you want to see it, email me). It actually is fairly simple to adopt CD, DevOps into your everyday practices barring a few exceptions.

As I said in my book published earlier in the year 2016 (Continuous Delivery) the first step to getting there is collaboration and something as simple as getting together at table with Dev, Ops and QA guys for lunch and walking away with no one killed is a start.

But, more seriously, automation is a start. It could be something as simple as regression. We can tackle world hunger and world peace later. I am going to address the finer details on the CD journey in later series.

For now Happy Holidays and have a great New Year. Oh, and enjoy those resolutions, keep up with them beyond Jan, please!

PS: Oh, and if you haven’t budgeted for it , no harm, no foul! Tweaks can me made to how you do many of the things in your engineering lifecycle already, to get on with the CD journey. Truth be told, CD is in our DNA, talk to someone @ Qentelli to get help on any of the things DevOps and Continuous Delivery.

Dear DevOps, I Hate You!

Dear DevOps, How are you? I have been meaning to write to you for a while now, just to tell you how much I hate you and to tell you that you are dead to me. Why you ask? Let me explain, DevOps but before I do that, a little background.

Since the day I heard of Agile and its power in enabling teams to think in small increments to gain big, substantial results, I have been a fan. The sheer agility and velocity the principles of Agile brought were exciting. When business and end users started demanding more frequent releases and higher quality applications, I even adopted extreme programming techniques and furthered automated testing efforts, to the extent that functionality was tested automatically (and magically) when I clicked the Build button. I couldn’t help but notice everything on the development and testing side working perfectly until code was moved to higher environments. Often times the bottlenecks were performance issues identified much later than I would’ve liked, security issues identified too late in the game and the worst being, IT operations, release and deployment teams. Why can things not be as smooth across the lifecycle I thought to myself and discussed when possible in forums where likeminded folks as me hangout.

And then, something wonderful happened. A wise friend of mine called Google, introduced me to you – DevOps he said and I gasped, first in disbelief, then in pure joy. I must say, I was fascinated – at first by you, your pure and simple thought process, and boy! Was it love at first sight?

I was thrilled to have found a friend, a confidant, an ally that shared the same thoughts and I finally found someone that can eliminate those bottlenecks that were bothering me, I had finally seen someone that can make Continuous Delivery a reality! I was thrilled the more I thought of the unlimited possibilities, the end less fun we all could have again and I could see the happy hours again like a light at the end of the tunnel.

One day, not long after I discovered you, during a conversation, a colleague referred to you as “Nothing but Agile, more like Agile 2.0” – He’s just Jealous I thought, nothing could dampen my spirits at that time. Now I think, How Naïve of me?

Fast-forward a few months. I conducted a workshop for a client on Continuous Delivery. In a meeting after the workshop with the senior IT leadership, you became the core of the conversation. We have DevOps! One of them exclaimed. I was overjoyed. I couldn’t wait to finally see you in action, in your full glory. I was shown a few tools, scattered across and used by the development and testing teams. I was surprised, definitely not even close to what I imagined you to be like. That same week, I was at a conference where I met an IT leader (who I had a lot of respect for) who proudly claimed, we have DevOps! I couldn’t wait to learn more, may be he could show me a picture. On probing, I learnt that he had a “DevOps team” that worked alongside his development, testing, release and IT operations. They automated a few tasks on setting up servers / virtual environments.

This time DevOps, I was shell-shocked. I was distraught.

“Nothing but Agile 2.0” “A toolset not adding much value” “A Team setting up servers / virtual environments” kept ringing in my ears. How wrong I was! Or was I really?

The more I thought about it, the more I loathed you, I started looking at you as a radical extremist taking sides and going rogue on the very thing you were meant to be. How I thought of you and how you turned out to be. You let me down! At that minute, I hated you and you were dead to me in that current form that people perceived and referred to you as.

I went back to the drawing board. I wrote down what you stood for, what you were meant to be on one side – You are a culture, a mindset, a philosophy, you bring collaboration, you eliminate wait times and at one point you stood for continuous delivery!

Along side, I started another list. If my vision was seamless and Continuous Delivery and Improved agility, velocity and more frequent high quality release my goal, what should I do?

This is what I came up with:

  1. Collaborative Culture
  2. Near Zero Wait times
  3. Continuous Development
  4. Continuous Testing
  5. Continuous Integration
  6. Continuous Build and Deploy to Pre Production
  7. Extreme automation that includes testing and manual tasks
  8. Continuous Release and Deployment to Production
  9. Continuous Monitoring and Feedback loop that enables proactive issue fixes that I find in production
  10. No more “tossing over the fence” mindset
  11. One Team – One Dream thinking
  12. Metrics that can help track status and health across the board

I was content with the list I had come up with, it looked comprehensive and one that could make my continuous delivery dream a reality.

As I took and step back and reviewed the list in front of me, something struck me as amazing. This is what (at least most of what) you – DevOps always stood for and intended to bring! Then I understood you. It was never your fault. It was perceptions of a few folks, circumstances, the changing tool landscape, and the way people interpreted what DevOps was!

DevOps, You are a philosopher, a way of life, and a way of truth! What you need is an ally, a conductor that can orchestrate, a collaborative culture and top down push that enables teams to adopt you as a philosophy. You needed Orchestrated Engineering to make Continuous Delivery a reality. And you, only you can make it happen. It is not only about Dev and Ops, it is about everyone on the value chain.

At Qentelli my friend, we understand you and you remain our philosopher for life. To us, you really mean TestDevSupOps, that is what you really meant to be and will always mean to us. We have implemented a methodology based on what you preached and have a comprehensive solution for continuous delivery, I recently published a book on it too, and it is called Continuous Delivery through Orchestrated Engineering and principles of DevOps.

Meanwhile if people chose to remain ignorant and use you as a toolset or as a team that performs continuous / automated deployments of environments and code, so be it. It doesn’t tarnish your reputation or take away your core essence.

My bad DevOps! You were right all along and I still rank you high up there in the Continuous Delivery Value Chain! I love you right back my friend.


A Fan!

Containers – A Way to DevOps

There are many ways to DevOps but one thing is certain as indicated in several prior blog posts, it is a culture, a mindset change and a prescriptive approach than rather being a process to be implemented in a specific way. It is much more than being a process and hence there are multiple ways to get there, what works for an enterprise is for them to determine. Fundamentally, the agonizing gap between the Dev and IT Ops has to be eliminated and an Enterprise must do everything in their control to bring that to near zero.

In exploring several possible options to achieving Continuous Delivery, I realized that the biggest divide exists in vastly different Development Environment Vs. “rest of the enterprise” Environments leading to last minute scramble by either the Dev or the IT Ops teams and typically leading to a Hail Mary effort to get the release completed. This trend must be arrested and it can! Bringing in several things discussed – Are Deployments standing between you and the happy hour will certainly help. In addition to the already discussed areas, taking a Container Approach can most certainly alleviate some of the struggles an enterprise would go through in this journey.

First, lets take a look at what is needed.

When evaluating new IT investments such as DevOps, Open Source provides great help in figuring out the key aspects of DevOps and what you could expect from DevOps and if it fits into your needs. It also helps you evaluate Commercial offerings better, and if they solve a problem that Open source technologies do not. But as with most open source, there is a problem, figuring out which Open source tools would help you achieve an end-to-end solution to your problem and most importantly how to stitch all of them together and make them play well together. Mind you, there isn’t one tool that solves all your woes – its all about Orchestration of all available resources.

DevOps is a chain and a platform that demands all players contribute and contribute big! Thus the need for multiple tools for achieving Planning, Source Code Control, Build and Integration, Automated Testing, Configuration Management, Deployments and Monitoring.

Below is a list of few tools that could be considered:

  • Git or SVN for Source Code Control
  • Jenkins for Build and Integration
  • Cucumber, Selenium for Testing
  • Chef, Puppet or Ansible for Configuration Management
  • Nagios, Icinga for Monitoring

The challenge I have seen at most enterprises is this becomes a toolset that they invest in and end up hiring a team “The DevOps team” to manage these tools losing focus of the end goal at times – bringing everyone together, rather than getting a toolset or team. Lets pause that discussion right there. Back to tools! Now, the set up of these tools can be challenging, considering the requirements for each, the integrations and the environments they demand. Without bringing onboard a ton of individual SMEs, What is the quickest way to set up all these tools, without having to invest on servers? Enter Docker.

I have followed Containerization for a bit there and I see that Docker is the most popular containerization platform that allows you to create multi-container a.k.a docker-in-docker deployments and brings a lot of flexibility in the way a container (one stop to address all your integration woes) application can function. Essentially, the developer might as well be working on the replica of a production container and so can everyone else in the value chain – Automated testers, release, config management et al. The one argument I hear at this stage is why not AWS or similar virtual infrastructure – I’ll address the Container Vs Virtualization in a different post – but to summarize Docker or any container essentially wins this argument over through the ease of instantiation, convergence, integration resulting in reduced lead times and eliminated wait times.

Consider this, during the planning phase, the Dev, Test, Release and Ops teams can essentially define the actual infrastructure including the base OS, DB versions, middleware and services stack and the actual run-time environments and the application into the same image. Docker Compose helps you compose your end to end DevOps environment using a Dockerfile and just by doing a docker-compose up” will have your environment up and running.

This “Converged Isolation” eliminates the variations that can occur in environments – Dev, Integration or production, thus giving the developers the super power – developing, building and testing in a production like environment from the get go, thus bringing more agility and velocity across the lifecycle.

Once you have all these tools orchestrated and integrated together, you have a true end to end DevOps environment ready to be utilized for your purposes, and when you are ready you can utilize any Container Services to deploy your DevOps environment for your full blown implementation.

Note that orchestration of different tools in the lifecycle is key to achieving end-to-end DevOps, and not the tools themselves. If you are sure implementing DevOps is way forward for your organization to achieve higher quality, continuous delivery but are not sure where to start, or need help with orchestrated engineering, Qentelli provides orchestrated engineering, quality intelligence, continuous delivery services and products to accelerate your implementation.

  • 1
  • 2