Is this software ready for release?

It’s hard, if not impossible, to answer that question without taking control of all the moving parts running when each release is assembled. Defining criteria for each release and presenting data on critical characteristics can help you make rational decisions about the software launch.
But, how do you make informed decisions when complexity is high, and speed is expected? The answer is automation, i.e., to automate the collection, visualization, and analytics of data that helps you to decide on to “push the release button.”

So, what information do you need?

  • Process – data about the creation process.
  • Changes – about all changes in the software.
  • Features & Fixes – about new features and important bug fixes.
  • Defects – about known weaknesses still in the code?
  • Composition – what is the content of this software?
  • Licensing & Policies – does the software comply with company policies?
  • Security – results from all security testing, detection, and analysis work.
  • Quality – results from all testing activities.

It’s important to have persistent data about the creation process and all activities related to it. Vital information for repeatability, traceability, and security reasons.
What activities should be addressed here? –> what code was checked out from what repository, what software was included from where, how was the build performed, what artifacts were created, how was the testing and security activities performed, etc.



You need to know about all changes to the software, of every kind and on every level.

What has been changed since the previous release? Who changed it, and why? Tracking everything is a necessity as modern software production is complex, with concurrent production activities, continuously evolving features, external components, agility, and speed, etc.

Tracing the entire lifecycle of all elements in each product iteration to obtain that essential “single source of truth,” requires full integration of the tools that different stakeholders use in the product development process.



A list of new features and significant bug fixes since the previous release.

For many reasons, it’s, of course, the most essential to know what features you are releasing, but it’s also important to understand how, where, and by whom they are implemented. Why? For transparency and security, traceability, and quality. You want to know what is done, not what is said to be done. The same goes for bug fixes.



A detailed list of known weaknesses in the code.

There are risks involved with every software release. Small problems may usually go unrecognized, but generally, if you have a more significant issue and still go ahead and launch anyway, the risks will be larger and may have damaging consequences.



You will need a detailed software Bill-of-Materials for the release.

What is the composition of this software, or what’s in your code? The increased use of open-source software has made it necessary to track all components that you include in your products. Each external component is a potential risk regarding security and license compliance.

Create a Bill-of-Materials for your applications, containing details on all software included, the version used and the license type for each. This should be a continuous effort where all changes in the composition must be flagged and handled.

Update : Read more about How.



Completed licensing and policies compliance checklist.

Open Source Software (OSS) will potentially provide you with a more efficient way to innovate, a shorter time to market, higher software quality, and more. That is why OSS is such a success in the software domain with a proportion of more than 50% of the code in the average software product.
The advantages are quite obvious, but there are some downsides to consider and manage also. One of them is to master the endless and dynamic list of license types and agreements associated with all component included in your software. It’s crucial that software with a (for you) harmful license type don’t find its way into your products.
Components, whether they are internally developed or external, may have usage policies associated with them. Policy compliance is also an important characteristic to consider when releasing.



Results from all security testing, detection, and analysis work.

Software security must be present to protect your software against malicious attacks preventing it from working correctly. Hackers can be stopped from using vulnerabilities in your code by implementing security measures on different levels. At the source code level by using tools for static analysis of the software, continuous penetration testing at the system level, and common vulnerability and exposures (CVE) detection and management for all external software.



Results from all testing activities, verifying the software for correctness, quality, and performance. One of the most crucial parts of any software development process.