You can now download the Release Modeling Visio stencil that we use to design release processes with our InRelease customers. I had been meaning to do this for a while now and I finally got around to it.
Why a release path modeling tool?
One of the difficult tasks in implementing a solid and repeatable release process is first to agree on what that release process should be and have all participants agree to it. The release path involves developers at one end with operations at the other end and testers and various stakeholders along the way. When I first started to visit customers to figure out what features we needed to include in InRelease, one of the first thing I would ask was to describe their current release process. What struck me is that most of the time no-one could describe it to me in its entirety. Sure everyone could describe a part of it; but I always had to cobble together the full story from different people using their own specific terms and vocabulary. Back in the day we did not call it DevOps, but that’s the DevOps divide I was straddling joyfully.
So, I developed a vocabulary and a standard way to design release paths so that I could draw it efficiently and have all constituents work off of the same common starting point. The next step is to define the target release paths and then take steps to implement it piece by piece, whether it’d be for automating it or just streamline a manual process.
The stencil is a tool to help with designing a release process. It leverages the Visio basics of dragging predefined shapes that corresponds to the decision elements we usually encounter to map your release path so you can obtain that overall vision I was talking about, like in this completed example:
Our release modeling approach
When I created the stencil it was as much to have a way to ask all the questions in the right order as it was to capture the answers. The steps are the following:
1. Identify your release scenarios. A new version, a patch with no database changes, and urgent fix to production. Each scenario needs to be modeled separately. Start with the “happy” scenario first and add the others afterwards. In the stencil we use this shape:
2. Define the stages you need to go through. These are the stages where some sort of inspection, whether manual or automated, will happen. They should be based on your governance requirements. These can vary per scenario, that’s why you want to model scenarios separately so as not to force more stringent requirements from one scenario to another. Some stage types: Dev, Dev Test, Integration, QA, Upgrade, Pre-prod, Staging, Performance, Demo, Training, Production, Rollback. In the Stencil the stages are more or less columns. We add them together one after the other to show the flow in the following manner:
Once you drag the shape you change stage name to what you need. You will add additional shapes on the stages in the next steps.
3. Define the environments. The environment is one or a group of servers on which you will deploy you application. These can be physical, virtual or cloud based. They can be updated, configured, re-created from a template or managed with Lab Manager, depending the provisioning strategy selected. In the stencil, you drag the environment box on the stage and name the server.
If everything is standard – standard server configuration and provisioning – naming it might be sufficient. If it varies from standard or none exist, I usually add the boxes on the next pages and add the details there.
4. Define which tests types you will run on each stage. This is actually the goal of the stage. What do you want to accomplish here in terms of tests and validation. If you have a test plan, this should be very easy to answer. If you don’t and you do not have a clear idea of what test results you are looking to obtain on a given stage, you might ask yourself - why make the stop at all? In the stencil, you can drag various pre-defined types of tests to the stage. Some are manual, some are automated – the icons reflect that. You can change the test types names to suit your internal nomenclature. I prefer dragging the tests at the top of the stage:
Note that these 2 last steps can be done in the reverse order. Sometimes we have to make do with the environments we have, sometimes we can get the environments to fit our test plans. Adapt accordingly.
5. Define the Owners and Approvers. For each stage that your application will go through you need to define who will perform the tests and other validations. This may be a person, a role or a group and there might be more than one approver per stage. It is not rare to have a mix of business and technical approvals required on a given stage in order to move on. This stems from the various types of tests the app may be required to go through. Whether in a manual process where these are signatures required or automated approvals requests in InRelease, you still need to define what you want to happen first!
6. Define the source. Define where the bits will come from. This can be a drop location or in the case of TFS users a build definition. For example, to find the bits automatically InRelease uses the TFS API to find the drop location of every build based on the TFS build definition. We also identify from which branch the build is created for that given release scenario. This ties the release side to the branching strategy. we find that One scenario-One branch-One build helps simplify the universe a lot! In the stencil, you pick the source branch+drop or the branch+build and drag them to at the beginning of the release path:
With TFS Team Build you don’t need the UNC path per say, I added it to show the option when not using Team Build. Of course, you would replace “UNC Path” tag with the actual value of the UNC Path.
7. Define the deployment mechanisms. The next step is to define which deployment mechanisms will be used on each stage. The deployment mechanism is intimately related to the technology and the packaging selected for the application. They can vary by component, database vs. website for example. As I mentioned in a previous blog post, I believe that using the same mechanisms throughout the release process is a very good idea as you practice your deployments over and over before deploying to prod where everyone can hear you scream.
In this step you will also uncover additional tasks that may be part of your deployment, such as configurations, starting and stopping services, launching tests, taking back ups and so on. These can be capture as text to be tackled later on.
8. Define the data generation. In this step you will define how will you generate your test data, or update it. Ideally, test data is generated using the system itself targeting just under the UI layer so that test generation also serves as regression testing. Test data is sometimes copied from production which is straightforward to execute but comes with its own sets of issues. Another case is to restore a previous version and then update it in order to test the upgrade mechanisms. In all cases, capture your data generation and update decisions in the stencil using the data shape and changing the text to reflect your decisions. Additional details on how to execute these choices will more than likely be necessary as you progress further.
Where to get the Release Modeling stencil
You can dowload the stencil from the Release Modeling project on CodePlex.
Once you have dowloaded the InCycle Release Modeling.vss file, copy it to your My Shape folder.
In Visio, to open the stencil, in the Shapes window, click More Shapes, point to Open Stencil, select the stencil, and then click Open. You can now use the shapes.
I hope you find this tool useful, I know I do. If you have any suggestions or questions, just leave a comment on this blog!
