As we continue to look at the book Accelerate, and the 24 practices that help you build a high performing organization, we come to Empowered Teams. The concept is simple, but the implementation can be complex.
Our research shows that teams that can choose which tools to use do better at continuous delivery and, in turn, drive better software development and delivery performance.
But, let’s face it, if you let every team use any tool that they so choose you’d have anarchy and you’d be in a worse place than you are now. So, where is the optimum spot to end up?
Continue reading “Empowered Team”
We’ve successfully navigated the first major section of “Accelerate” journey: Continuous Deployment. Now let’s take a look at the Architecture capabilities that you need.
It’s no surprise that a “loosely coupled architecture” is necessary for the organization to be high performing. A loosely coupled architecture allows for incremental changes to occur without relying upon other changes to be implemented concurrently.
So, what is loosely couple?
Continue reading “Loosely Coupled Architecture”
Everything that we’ve done to this point – Version Control, Deployment Automation, Continuous Integration, Trunk Based Development, Test Automation, Test Data Management, Shift Left on Security – has all been leading up to one thing: Continuous Delivery.
Continuous Delivery is all about having the application deployed continuously, whenever needed. But there is a key piece that really needs to be understood before you head down this path.
Continue reading “Continuous Delivery”
Next on our journey to Accelerate the organization? Security. Imagine that, thinking about security up front will allow your organization to accelerate the building and scaling of applications.
We need to “shift left” on security. To “shift left” means to move something that is normally done later in a process to moving it up earlier in the process. In a timeline that goes left to right, we “shift left” or move it earlier in the timeline.
But what does that really mean we we are talking about security? Continue reading “Shift Left on Security”
We’ve talked about automating the testing, but we also need to talk about Test Data Management. You can’t automate your tests unless you know what data you are dealing with. If you pass a function the value “PI” and expect it to look up the value in a table and return “3.14159” back, but someone changed the value in the table, your test will fail, even though it worked properly.
False negatives and false positives can be the result of bad code or bad data. To reduce the problems associated with the data you need to understand the data you are dealing with and ensure that the data on test run #1 is the same as the data on test run #100.
You need to manage your test data.
Continue reading “Test Data Management”
So the next step in our “Accelerate” journey is Test Automation.
It sounds simple, doesn’t it? Put a couple of scripts together, do some testing via a batch job and BAM you’re done. Walk away into the sunset, with the sound of your spurs the only thing that can be heard for miles.
Too bad that this image is just a fantasy. Simple it is not. Priceless it is.
Continue reading “Test Automation”
Next, trunk based development.
To understand trunk-based development you need to understand that the “source of truth” for an application, what is supposed to be running in production, is something called the trunk. When you make changes, you make those changes in a branch and then merge the branch back into the trunk so that it contains all of the changes that have been made.
So, trunk-based development is an extension of what was discussed yesterday with regard to continuous integration. This is the next step. This is the target that projects should aim for. Continuous integration on steroids.
Continue reading “Trunk Based Development”
Continuous Integration is the next step on our journey to a high performing organization. If you are using version control, then you most likely created a “branch” off the main trunk to make changes to the source code. Essentially you took a copy of the source code and declared that here is where all of your changes were going to be made.
And then, when you’re done, you merge your code back into the trunk so that it is available for everyone to see.
And therein lies the problem. What if you have more than one branch? What if you have five or six branches going at the same time? What is the source of truth for any piece of code? How are changes merged with other changes? The problem is easy to see, but so is the solution: continuous integration.
Continue reading “Continuous Integration”
OK, multiple days in a row about the same book “Accelerate: Building and Scaling High Performing Technology Organizations“. So far my personal challenge is working out … but this is day 2 of 24 so I will control my self-congratulations until later.
Today’s topic? Deployment Automation.
You might think that this is a no-brainer, that deployment automation has to improve the quality of an application. But that’s not always the case. Continue reading “Deployment Automation”
Yeah, I know, it’s surprising me comment two days in a row. I’ve been “out of sorts” for the past little bit but I set myself a challenge recently that I intend to see through. I recently started reading the book “Accelerate: Building and Scaling High Performing Technology Organizations” and I really wanted to share the results with you.
The authors behind the book have been doing the “State of DevOps” reports for the past few years and have gathered an amazing amount of information and statistics to back up their statements. According to their data there are 24 key capabilities that drive performance in the software delivery organization.
Those 24 capabilities have been grouped into five larger categories. So, the challenge I gave myself was to give you one of these capabilities every day, although I would recommend picking up the book and reading it for yourself.
Continue reading “A Long Journey”