The Actors in Continuous Confidence

By -
Over the next little bit, we are going to delve into how Continuous Confidence changes our perspectives and rolls as we seek for further confidence in our code release.

I want each of us to think back on when we were first introduced to Continuous Integration. Maybe this is the first time for some of us, so let me recap.

Introduction To Continuous Integration

Thoughtworks introduced a new way of developing code. They said, always integrate your code as quickly as you can. His allows for fast feedback. So their guideline is shortlived branching, maybe a day at longest. Keep everything on master, and keep it releasable.

Now I remember when I was first introduced to Continuous Integration. We made an automated build  and test system. We were loving it. We said, "Ok, everyone develop solely on master." And we were off. So there we started and we did what "everyone else" did I tell he world: we called it continuous integration. And yet, as we went further and further, there were frustrations. We found it made our developers more frustrated when a test failed for no reason, it was flakey. We found that we went faster and released more often, but we broke production more often than not.

We probably all have stories like this. And so, we revert back to doing a slight modification of what we were doing and continuously building. So why didn't it work? I submit because we weren't focusing on be confident about our build. When we focus on Continuous Confidence, we focus on making a mind shift that changes who we are and what our rolls are. Today I will introduce those rolls and over the next few posts, I will elaborate on each one.


  • Developers: The Provers - it is the developers' responsibility to prove they wrote code as was intended.
  • Quality Assurance (QA): Behavior Specialists - QA is responsible for translating behavior for developers and verifying that what the developers prove is actually how it should behave.
  • Product: Vision Leader - Product keeps a traditional roll as a vision leader, but makes sure they discuss the behavior of the product with QA and Development.
  • DevOps/IT: The Enforcers- DevOps/IT make sure things run smoothly. They get to ask the hard questions and enforce whether something goes live based on how you can measure and monitor success of the code.
  • Customer Support: The Medics - these wonderful people get to speak with traumatized customers and determine how we can gain more trust with the customer and what it will take to get more confidence with them.
  • Marketing: The Presenters - marketing needs to focus on gaining trust in a real way. Focus on presenting the message of trust in the product.
  • Sales: The Deliverer - Sales will show the future clientele that they can trust our product to solve their problem. They need to trust the product first and foremost.
Here are some of the rolls. And as you see, each one will play an intricate roll leading to overall successful releases over time.

Comments

Post a Comment

Popular posts from this blog

Not All CI Solutions Are Created Equal

By -
Are there any of you out there who have attempted Continuous Integration, Delivery, or Deployment, and had it fail? Have you ever just given up because it was over complicating things? People were not happy? Believe it or not, this is very common. I have heard many stories where organizations have failed at implementing CI. So first and foremost I want to say: it's ok! We all recognize the value of what we get from doing CI, but in reality, in practice we need to be more practical and pragmatic in our approach. May I offer some counsel. Implement Countinuous Confidence This may seem strange at first, and probably expected since this blog is all about Continuous Confidence, but really, truly, this is he first step. Focus on your confidence points.  Generally, when I see failure in the CI world, it isn't the methodology, but rather the lack of confidence in the process that is causing the problem. Generally speaking, I see people wanting to implement CI in here organization becau...
Read more

Stop Talking About Continuous Integration

By -
There. I have said it. This is the elephant in the room. For years, we as Dev Ops professionals, and as an industry have been talking about how to up our game using Continuous Integration.  We talk about our Software Development Life Cycle (SDLC) or how we need to improve our QA Processes and deliver faster and with higher quality. We start implementing Continuous Integration and we try to implement Continuous Delivery and or Deployment. And you know what happens? We fail to do it the way others did. There are some examples that we try to wedge ourselves into. We try hard to mimic what others have done. And so we fail over time. Some of us, we get to where we want to be, but others...yeah...let's not talk about it! So what should we be doing? We should be talking about Continuous Confidence. We should be talking about what processes and what things are we doing that will help us get better confidence in our product. What will give others better confidence in our product. When...
Read more

Legacy Code: What to do About it

By -
There are a lot of questions around legacy code. If we ask any developer who is new to the organization, they will most likely say: REFACTOR! Our first knee jerk reaction is to not touch the legacy code, so we kind of dismiss the new developer saying that. However, we should look more deeply at what they are saying. The Code is Messy Generally, when dealing with legacy code, it is messy! Let's face it, when we start writing code, we ignore certain design patterns for others because there isn't a need. Once we get large enough, something has to be done about it. We need to stay focussed. If we feel that we are assigning one senior developer to fix legacy code, while 50 others are still using it, we will,never fix the code. Continuous Confidence comes from looking at the code and feeling calm not erratic. The Code is Antiquated When we hear refactor, His might mean as well that the code doesn't follow today's standards. So how do we make it so? We need to refactor...
Read more