Monday, December 23, 2019

Automated processes are great. However,



An automated procedure that is verified to "run" is not the same as an automated procedure that has been verified to have "completed properly".

Today, I counted 2 on-line sources of information I use that haven't had important information updated for several months now. 

Because of the missing updates, other parts of their sites aren't working. In one case, their API works but shows only partial information and some information is completely wrong.

If you have automated procedures that update web site details, look-up tables or anything that rarely gets looked at by a person, consider writing some verification tests that run occasionally to make sure your infrastructure is as it should be and that automated procedures are actually completing successfully.  

Perhaps one day you'll get used to writing the tests first!

The more complicated the automated procedure or update, the more likely something will break without you knowing it. The likelihood of this increases if the changes originate from an external party or system.

The worst time to find out an automated procedure is not working is when a customer calls.

For now, just writing tests to confirm what you think will go a long way.

Ask yourself:


What process (manual or automated) do I have in place to make sure scheduled background or automated updates are actually completing properly?

The results may surprise you.











Friday, June 28, 2019

A thought about Quality



Ask yourself....

Is quality determined by the creator or the consumer?

In your context, who is defining quality?




Wednesday, November 21, 2018

A phrase for your future. Test Driven Development for Infrastructure as Code

Consider spending some time researching the following terms...
  • Test Driven Development
  • Infrastructure
  • Infrastructure as Code
You will find an abundance of information on any of them. There is some, but very little combining the various concepts into one.

Consider that some day the phrase "Test Driven Development for Infrastructure as Code" will become widely used.

As technology gets deployed automatically (think Electricity Grids, Gas or Oil Pipelines, Autonomous Vehicles, Trading Systems, Health Care systems, etc.) the time required to test new features will become harder and harder to execute in a reasonable time-frame. 

This will become evident as you research and learn more about the term "Infrastructure as Code".

Testing in this realm will become increasingly burdensome as IF statements are added to deployment scripts to accommodate different versions of hardware, operating system or environments. 

To help yourself, remember this one question....

How do we know all the security patches and updates are actually there after the deployment script says it is complete?". 

Manually will take too long and might already be too late.

Note: For the novice. It is possible for the script to be complete and indicate completion. However, critical updates have not in fact been executed. If you are not sure how this is possible, ask someone you trust to explain how this is possible. Ask about increasingly complex IF statements.

An answer to this question will ultimately become...

"Test Driven Development for Infrastructure as Code"

As a bonus, this approach will help to bridge the gap between infrastructure, software and testing. This excites me as I enjoy it when people with various backgrounds have the ability to come together to solve or work on a problem.

If you want to learn more, I encourage people in these different groups to spend a bit of time participating in events or conferences put on by the "other" groups. The future synergies might surprise you!  

Enjoy what you learn :->

Mike Caspar






Wednesday, June 27, 2018

You are the Product Owner of Your Life


For my agile aware friends and colleagues that are struggling to make big changes in your lives because of their complexity:


Consider that You are the Product Owner of your Life.


Use some of the tools you already know to remove complexity. It may help.








Friday, March 9, 2018

TDD for Infrastructure as Code. Collaboration with security and governance.


One of the benefits of using a Test Driven Development (TDD) approach to Incremental Infrastructure as Code is that the same tests that were used to build out the system can later be used to monitor the system for security or state.


This can be a great way to help collaboration between development and security or governance folks.

Consider reaching out to an experienced technical coach on TDD or BDD to learn more.

A link to a potential illustration of how this might work is in the references below. 


Reference:








Friday, March 2, 2018

Getting started with Test Automation for Incremental Infrastructure as Code

Today, I was reminded about a simple approach that has worked well for me in the past.  

When you do something manually for the 3rd time...Automated it.

Perhaps it can work for you.







Thursday, January 18, 2018

Could you stop development?

In your environment... 

If you wanted to stop development of a product or feature... Could you?

A few potential questions to consider about your context...

Does the system you have in place, provide a mechanism to stop non-valuable work for the benefit of the company without fear or recrimination? 

Do teams know what to do to stop non-valuable product development?

Is it considered Failure or Success to stop development of a product that will not deliver value?

Enjoy.