How Healthy is Your Product? - Delivery Pipeline Check

Tags:
2018 11 01 head

You are developing your product using agile and lean approaches.

How can you check your approach and distill improvements? A health check of your product and your development approach is certainly a good solution.

This post is the second of a series identifying health checks with different focus. We will identify strengths, potential weaknesses and hopefully find room for improvement.

How you build and deliver your software product has direct implications on your liquidity and cash flow. Improvements in your delivery pipeline have a direct impact on your finances.

Rules

The patient solely decides if a health check shall be performed. The effort and depth of a health check are defined together with the patient. The findings are considered confidential.

A short check with a feedback workshop presenting the insights requires around two work days.

A deeper and more intensive check requests more effort, between one and four weeks. Upon completion, you can also hire a coach to implement selected findings and durably improve the health of your application. The findings are often clear and the measures are straightforward. The real work is to consistently implement the measures.

I have the same personal challenge when trying to lose weight or improve my running form. The long-term implementation is the crux.

Delivery Pipeline Checks

How reproducible, fast, and economic is your product deliver pipeline? At the end of the day, you regularly deliver a reproducible and trackable product version to your customers.

One nice aspect about delivery pipeline checks is that a whole set of tools and methods emerged with the DevOps movement. You still need an expert to tune the diagnostic to your company’s specific needs, but the approach is well-documented.

Below is a list of capabilities we have built up over time for delivery pipeline checks. Use common sense and strategic goals to identify the objectives you want to measure. Expertise is necessary to define values to measure if the source code of your product reaches the selected objectives.

  1. Continuous integration pipeline with quality checks and automatic tests.

  2. Continuous delivery pipeline packaging the same binary to all your environments.

  3. Continuous deployment if adequate for your solution, certainly it is adequate for the test and integration stages.

  4. Automatic source code quality checks and mandatory quality gates.

  5. Automatic unit tests, integration tests, and end-to-end tests.

  6. Golden Trunk in Git.

  7. No branches or only short-lived branches shall be the policy.

  8. Zero bugs policy eliminates the change management processes and board for errors.

  9. Traceability of specifications to deliver features and product versions

  10. Semantic versioning and API documentation

  11. Configuration and infrastructure as managed artifacts

  12. Generation of documentation part of the delivery pipeline

  13. Monitoring and alarming

  14. DevOps pipeline analysis provides another look at your processes

    1. Code development and Review, Continuous integration and build status

    2. Continuous testing and business risks feedback

    3. Artifact repository and pre-deployment staging

    4. Release automation including change management and release approvals

    5. Infrastructure configuration and management and infrastructure as code

    6. Applications performance monitoring and end-user experience.

You should know how often you can deliver your product without failures and track your lead time between fixes. The overall goal is faster time to market and improved delivery frequency.

The overall features and processes can be implemented through your development organization in less than a year. Stop evaluating, start implementing!

Continuous Integration Practices

Check your process to see which continuous practices you are really mastering

  • Maintain a single source repository - no long-lived branches.

  • Automate the build - no manual inputs, no manual configuration, automatically triggered.

  • Make your build self-testing - TDD, ATDD, static metrics, semantic checks.

  • Everyone commits to the trunk every day.

  • Every commit should build trunk on an integration machine.

  • Fix a broken build immediately - lean red button stopping production, everybody helps fix the broken build. Keep the build fast - We are talking of minutes, not hours.

  • Test within an integration staging area which is a clone of the production environment. The goal is to have docker images, virtual network, and in-memory database to be fast.

  • Make it easy for anyone to get the latest-packaged release.

  • Everyone can see the build status - transparency, information radiator.

  • Automate deployment.

Posts in the Health Check Series