Continuing my series on Release Management, I would like to discuss the Build and Deployment Team as well as the Deployment Activity in Software Release Management. Now you are probably wondering, what the heck does that have to do with a picture of a Nascar Race Track shown on the left? Well, I have been around race cars and car racing since a teen, and worked on several local race teams helping friends compete in local Nascar events for many years, and I still admire and attend the Nascar races each year. And knowing the way this sport operates, or any team sport for that matter, I think the analogy of the sport of racing is a good one to use with regard to resourcing build and deployment teams.
The analogy of a race team or pit crew is similar to the team you assemble for system deployments doing that build and deployment activity. If you look at Hall of Fame Coach Joe Gibbs who went from leading a championship team in the National Football League (NFL) to leading championship Nascar Racing teams, you can see the team he assembles is the strength of the success. And, I always said: “You are only as good as your Pit Crew.” The reason is simple, in racing, there is more to success than just the driver. It’s a team sport. You can have a skilled driver but if they pit and their pit crew is slow at servicing the car or miss a key important step, they come out last. So, each team member and each crew member has to be depended upon for the skills they are doing for the team. That team make up is not just at the track but all the way back to the office and shop. If you are practicing Release Management, you will quickly learn the success of that release activity comes down to the make up and stability of that Build and Deployment Team, or the make up of the DevOps team exercising this activity, or the extended team who is called on as part of the deployment plan. It’s a bond. As a leader, you need to assemble and encourage the team members to form that bond. It is also up the Release Manager to pull the plan together. Failure to plan, is planning to fail. So, have the right leadership to assemble the team, build the team, and build out the expertise. Just as Coach Gibbs did everywhere he went, assemble a team of members and then drive that team to their best potential. How does team building differ from the DevOps or Waterfall Development?
Well, in a DevOps model, you are lucky to work with the same team, but having the make-up of the team in DevOps is most likely focused on the specific product or application that you are supporting in that model. The resourcing of that team is also key for their own level of success with each role carefully selected. But what about the external areas that support you may rely on as part of Release activity? The dotted line to other areas, shared services, networking, support groups, business, or even other DevOps teams if this is a coordinated release for a program? That federation for release activity is the reason why I think the DevOps model needs to a solid Release Management function as a clear role that’s not only participates in the release planning of the current sprints and project, but also has visibility beyond that to the external services and infrastructure teams and their release planning. That external view brings in planning knowledge of outside business events and timing, infrastructure planned events, and also starts to create a community of practitioners in the Release practice beyond the product and project they are working on. They are a value to the team and the other teams.
Think of the integrated release that happens in larger programs that involve data loads, initial data loads, multiple teams, migrations, and the timed events of deployment of changes in a proper order. All of these things have a dependency on resources. In the DevOps model, you have a bit more control since the resources are pretty steady resources in the team. And if you think of the DevOps team, they become really experienced and skilled in that product life cycle. However, as I stated, there may be external resources needed to assist in deployment for a larger program release. The visibility beyond that team is key for the Release process. The same applies to Waterfall development, only you have to assemble that team within the project for this specific function. So, how do we replicate the project team make up similar to that you find in DevOps?
In the Release and Deployment process, the establishment of a reliable build and deployment team to handle these activities in the non-production environment and handle the live production environment deployment is mentioned in ITIL within the Release and Deployment Management function as well as the Build Test and Environment Management function. They also refer to the deployment activities and the make-up of the team doing this event. In practice, this is a team reporting to the Release Manager, who then reports up to Project Management. There is also a trust factor that the release team must rely on with its members. This team is your skilled team to apply the changes in a deployment activity to the live environment.
It is preferred to have the same team to do the deployment activity of the changes from Dev to Test so that the team is learning and repeating the events in non-production cycles. That’s extremely valuable. So, similar to how the DevOps team practiced and became really skilled in the product, this newly assembled team is becoming experts in the release process to apply these changes. They are instrumental in the deployment planning and the main people you count on to deliver the release. Their expertise is more focused to delivery and the actual make up of the product to know how that product is changed for specific release activity. They have the skills for automation of build and deployment, and also have the in-depth knowledge of what the change is physically doing to the system. It’s a tremendous value learning the effects of release activity while it goes through the Systems Development Life Cycle. Knowing what changes are made are as important to knowing the effect of the change. Release activity is a cause and effect, and having the team experience to know this will pay off.
Glenn Owens Racing (Used with Permission)
So, using my Race Car analogy, on the track in a race car, it is not all about the driver and their skill. It’s the team approach that lets the talent and skill come out to 100%. The car and components have literally thousands of points of change that can affect how that car is handling for the driver. For this reason, similar to what you find in making changes to a system, the baseline is key and documenting how and what changes are made are also key. It’s not just tracking the change, you also need the knowledge on what that change will do (cause and effect). It’s a bit more difficult since there are other external factors on the race car, like the track, weather, and wear. But, then it is down to the experience of the team. It’s the experience on knowing that knowledge with what the component level will change that is key. But in general, the set up of the car for a track condition is tightly controlled similar to what we do in software configuration management.
Software Configuration Management is key to understanding and tracking your changes of the Release. You have a baseline configuration, and from that point you branch for specific changes being made against that baseline. You also need to know the impact of the change. Then, you get down to the people, or crew who are specialized in looking at applying these specific changes and also carefully looking at the change to see if it could impact some other functionality. In software release, you have similar situations with programs and projects, and you rely on this team knowledge doing the build and deployment activity, or the release team to help assist you get the deployment into the live environment successfully. The knowledge of learning the application of the component level changes and their impact is one of the reasons I value the build and deployment team. It is also one reason that I like to use the same team for subsequent release activities with the same product.
As this team matures, it is also the team that visualizes the release, looks beyond the activities, and helps to find the “gotchas” when doing the release planning with the Release Manager. The make up of this team is similar to the Pit Crew who assists the driver to get to the Victory Lane. The crew helps tune the car, avoid the pitfalls, and generally supports the driver. They are also the ones with the doing the support after hours or any hour of need. In the Release process, it is literally the team who assists the Release Manager to get the Release completed successfully. And, as the Release Manager, you really need to rely on the team assembled doing these activities.
In larger deployments, assembling a solid team is a key activity and should not be taken lightly. This cross-functional, cross-platform team is assembled, and charged with being able to handle the change or events that can come up, and also available during some hours typically in the evening or off-peak periods of the time to apply the change for the business. For smaller deployments, it can be a single team member filling this role, but that member is gaining the same benefits in learning the build and deployment space for the project and operations teams. For specific product releases, this deployment team is usually counted on, and called on for subsequent release activity, so it is also helpful having a steady team without a lot of resource turnover since the knowledge of the application and all the integration work is a key benefit. Plus, it builds a team community of practice around Build and Deployment who get really good at technology and deployment activities. All of this aids in a solid Release Management process!
William is a certified Practitioner in IT Service Management for Release and Control, with experience in Global Change, Configuration and Release Management. He is also an experienced Project Lead in delivery, IT Automation, systems implementation, build, deployment and release practices.
This article is in a series of articles around IT Change, Configuration and Release Management using ITIL’s Foundation Framework.
Copyright. William Mantz 2016. All Rights Reserved.
Images used with permission from GNU, please see Image Description or Alt Tags for attribution.
William's Grab Bag 