DevOps Key Metrics

What I find most compelling about the DevOps metrics listed below is the fact that control of almost all of the metrics can be gained by mastering the first metric in the list. The metric that seems to tame all others is the Number and Frequency of deployments / software releases. If we strive for the seemingly extreme goal of 10+ Deploys per Day the milestones that we much achieve to reach this goal end up covering all of the remaining metrics. For example, if we are able to deploy 10 times per day without losing or pissing off every single one of our customers we must have reduced the volume of defects, number and frequency of outages as well as cost of those outages. As the story goes in order to deploy 10 times a day most everything in the delivery pipeline needs to be automated therefore automated testing should reduce the Number of Defects and the cost associated with fixing them. By the same token if the deployment is automated the Number and Cost of Resources associated with deployment should be reduced. Lastly in order to deploy 10 times during a normal workday of 8 hours (480 minutes) our deployments must be done every 48 minutes. If we intend for our customers to actually use our solution the actual deployment must take significantly less than 48 minutes! As a result, Mean Time to Recovery and Mean Time to Change must go down as changes and fixes can go out in the next deployment within 48 minutes.

Number and frequency of software releases
Volume of defects
Time/cost per release
MTTR (Mean Time to Recover)
MTTC (Mean Time to Change)
Number and frequency of outages / performance issues
Revenue/profit impact of outages / performance issues
Number and cost of resources

Storing Infrastructure Secrets in Script

When migrating your organizations culture to the DevOps way automation is a key component. Not only automation of builds and testing but also automation of infrastructure components. As I’m sure most readers are aware the build out of infrastructure components usually requires elevated permissions using credentials that we would prefer not be widely published. How do we accomplish this level of automation while still keeping the necessary elevated permissions secure and still allow team members that don’t necessarily have required permissions to run the scripts?
Below are a few examples of secure credentials storage in infrastructure scripts.

SharePoint Blog Font changes when publishing from MS Word

If you are using Office365 and hosting a Blog in addition to your “Public Website” it’s a good idea to make yourself aware of the default Fonts and Styles and how they differ from the default Fonts and Styles in Microsoft Word if you are using MS Word to author your blog content.
Recently while discussing templates used to publish FaceBook Posts, Blog Posts, Articles, Courses and Labs the issue of the difference in appearance of certain Fonts and Styles as they are published to a SharePoint Blog from MS Word. There is a fix for this if you are willing to dig a little deeper but for the purpose of this post I will simply illustrate the key differences and a basic work around that will make your posts look as you intended when they are published to SharePoint.
When we start in Microsoft Word with the Font Styles in Figure 1 we end up with published content on our SharePoint Blog that looks like Figure 2.

Figure 1. Font Styles as they appear in Microsoft Word before publishing to SharePoint Blog.
First the SharePoint Blog Post Title uses the same style as a Heading 2 in the Styles list in MS Word so using Heading 2 anywhere in your blog post is probably not a good idea. For topic titles I recommend Heading 3, Normal for body text and Intense Emphasis for notes and callouts with the keywords / phrases in bold.

Figure 2. Font Styles, Colors and Sizes as they appear in Microsoft Word before publishing to SharePoint Blog.
After publishing we end up with changed Font Styles, Colors and Sizes most things appearing larger than they did in MS Word, however some appear smaller. So it’s good to know in advance what those changes will look like so that you and your readers are not “unpleasantly” surprised by the format of the new content you have just published to your SharePoint Blog.