Production software is reusable software that needs to be reliably, regularly delivered. The distinction of "production" software may be a specific designation, coupled with increased oversight and support by an IT organization responsible for maintaining a level of service within the organization and with the organization's customers. But there is just as often no official "production" designation; just that the software is important enough to the organization that there are requirements of rapid turnaround on bug fixes, or delivering new features on a predictable schedule.
There is ultimately one driving question with creating production software:
- How do I consistently produce a reliable release when needed?
The focus for production software is on removing manual steps to ensure we can produce a reliable release whenever needed. Effective automation not only saves time as you adopt additional software development tools and workflows, it makes it easier for developers to review and contribute to each other's code. This is useful for a single developer, and essential for large teams of developers working together on a codebase.
Address these challenges with the following tools and practices:
- Build Tool
- Continuous Integration / Continuous Delivery (CI/CD)
- Code coverage analysis, Test Browser
You can absolutely adopt the tools for production software for reusable software. In fact, it's common for new project templates to automatically set up these tools. Many software developers wouldn't conceive of starting a project without them. But some of the investments in automation and robustness might not be worth it for projects that don't release often.
As a software project grows, it can require multiple steps to test and release it. For instance, if you have MEX files, you will need to build them before you can run your tests. You want to verify that code complies with your coding guidelines. If you release your software as an installable MATLAB® Toolbox (MLTBX) file, you may want to build the file after your tests pass. We earlier introduced the practice of including these build directions in the README.md. But this still requires each developer to read, understand, and manually apply the build steps. To reliably and consistently produce a new release, you'll document and automate the build process using a build tool.
The Build tool provides a standard programming interface to create and run tasks in a uniform and efficient way. You define a build plan comprised of tasks like running tests or building MEX files. You define relationships and dependencies, like saying MEX files must build successfully before running tests. It's then easy to run any or all of the tasks with a single command.
A well-written build plan also makes it easy for additional developers to work on the software because it documents and automates the steps they need to follow to build, test, and release the software.
Each developer makes changes to the software independently. In addition to testing their own code, they need to test how their changes impact adjacent parts of the codebase. And you need to test the behavior when code changes from multiple developers are defined together. It's easy to reach the conclusion that testing needs to be automated to ensure all of this happens.
Continuous Integration / Continuous Delivery (CI/CD) are practices designed to make software development more efficient and reliable. CI/CD automates the process of building, testing, integrating, and releasing code. Whenever you make changes to your MATLAB code, a CI/CD system can automatically run your tests, check code quality, and prepare your software for release, all without manual intervention. By adopting CI/CD, you ensure that your projects are always up to date, well-tested, and ready for deployment, making it easier to deliver high-quality solutions to users and teams.
CI/CD systems are typically configured by platform engineers, the people responsible for building and managing development infrastructure. Platform engineers can integrate MATLAB with popular CI/CD systems including GitHub Actions, GitLab CI/CD, and Azure DevOps. Once MATLAB is integrated, the owner of each repository is responsible for configuring their repository for CI. This typically involves writing a YAML configuration file (a text file with .yml or .yaml extension) using the syntax of the specific system. Example repositories on GitHub provide basic and advanced examples of using MATLAB with these different systems.
GitHub® Actions is the easiest CI system for the Reluctant Developer who does not have support from a Platform Engineer or Developer. MATLAB Actions simplify the use of MATLAB with GitHub Actions, including setting up MATLAB (all releases since R2021a on all supported platforms). Use the Generate a GitHub Actions Workflow for MATLAB web page to automatically add a YAML configuration file to your GitHub repository.
The MATLAB build tool is designed to work in conjunction with CI/CD, allowing you to reuse the build plan you created for building and testing on your local machine. The Run Build MATLAB Action simplifies this setup with GitHub Actions.
Each unit test verifies behavior of just a part of your code - for instance, a given set of inputs to your function. But what if the behavior of your function depends on the values passed in? Maybe your function behaves differently when the input is negative, zero, or positive, or has special-case behavior to avoid dividing by 0. To preserve behavior while updating your code, you need to be sure you have a test to cover each of these cases.
Code coverage analysis tells you which parts of your code are actually exercised when your unit tests run. More importantly, the analysis tells you which parts of your code are not exercised. This points to where you need to write additional tests. When a system is used in production, high test code coverage is essential to have confidence that each release meets quality requirements. Track code coverage over time to monitor progress in improving coverage and ensure that new code is sufficiently tested.
You can automatically analyze and report on code coverage when running tests in MATLAB. The easiest and most convenient approach is to have the Test Browser automatically generate a code coverage report after running tests. The report shows which functions and which statements in your code were tested, and which were not. Use the Build tool TestTask to generate these code coverage reports in your automated build pipeline. MATLAB Test adds advanced types of code coverage and provides a Code Quality Dashboard that summarizes code coverage and other quality metrics for a project.