Process in the ENS DevOps Journey

Body

If you had a chance to check out my previous blog on changing our culture then you may recall that we identified the three pieces of DevOps as Culture, Process and Tools.  This blog will discuss how we addressed the second prong of the DevOps journey for ENS.  

When the ENS journey began, we had to look at the process focus areas that made sense for our organization.  We decided on Continuous Improvement, Continuous Integration, and Continuous Delivery.  Once we identified the target areas, then we had to define what those mean for ENS and what initiatives we could manage with our current workload.  Here are some examples of the initiatives we tackled as part of the process piece of our journey.

Continuous Improvement - The initiatives we decided on were based on pain points and areas of improvements that we could only learn were needed from going through the exercise of value stream mapping.  This process is time consuming and even a little bit tedious but it really is crucial for kicking off any DevOps journey.  Most of us are too ingrained in our own daily processes to see where areas of improvement are needed and it often takes someone indirectly or not at all related to the process to ask the necessary questions.  
 - Performance issue with the publications review tool: When going through the publication reviews process from the developers' stand point, we learned there was a performance issue with the tool that developers use to review publications.   This is something that was considered part of the Information Development (ID) process but the issue was on the developer/reviewer's side.  Had we not looked at it from all the parties involved, we might have overlooked this issue.  We engaged the team that supports this tool to upgrade their database version, significantly improving end-user performance.
- Some items were obvious, such as upgrading tools and migrating to newer versions of our internal source control manager to allow better collaboration and increased functionality.
- After reviewing the daily build process in our core workgroup, we realized we were starting our builds over an hour earlier than was necessary, so we moved the build time out and this gave the development team more time every day to check in code.

Continuous Integration - The first step was to identify what CI meant to us, the ENS organization.  Where are we integrating continuously?  With whom?  How will we do it?  We know we are agile and we know that Systems Verification Test (SVT) doesn't need to wait until we complete every line item to begin testing, so when we looked at our product and our customer's needs we knew that a daily code delivery to SVT was our who.

The biggest goal here is to prevent build failures, which slow the availability of code to test.  Our organization has a build verification test (BVT), or smoke test, that every new build must pass before it's made available to test.  We determined that we could reduce the number of BVT failures by making that BVT available to all developers, so they can run it on their patch before integrating it into the build.  We are also working on beefing up our collection of automated test buckets and making them easily available for developers to run on their patches before integrating them into the build.  This emphasizes a key DevOps principle, which is to fail early and cheaply.

Continuous Delivery - Again we had to decide what this meant to ENS.  (See a theme?)  We know who we are and who we are NOT.  We aren't writing applications for a mobile device or updating a search engine.  We are a strictly on-premises product that is built on security and stability and our customers do not want frequent new versions. But we need to be able to get feedback earlier in the development cycle and to do that we cannot wait until a beta program that starts near the end of a two-year release cycle to get customer feedback.  So we took the Configuration Assistant piece of our product and made pre-Beta development code available to select users.  We provide drops and ask customers to try certain items out to get their feedback that will help guide us in our work to architect a really great end-user experience.  This is not a simple task and there was overhead with getting it set up and there is overhead with maintaining it, but what we get out of it is really beneficial to creating what the customer wants and needs.

As our journey continues we are always looking for new initiatives that fall into our process focus areas that will enable us to become more efficient in our day-to-day execution and eliminate wasted cycles.  If you are interested in how we got started with DevOps, check out our first blog in the series, Enterprise Network Solutions approach to getting started with adopting DevOps for z/OS.