Software Process Automation
Project Overview
A development life cycle. In addition, quality assurance audits and system testing. Process can take months, but the goal of the project is to reduce the time from months to days. Each part of the process will be integrated with the build.
Project Approach
Treating the inputs to the software process as code. First, encoding the steps that it takes to produce an artifact in a domain specific language, then using a tool to execute those steps and produce a final output.
Test As Code
Normally, Blackbox testing exists in a software testing document with procedures that are manually run by a developer. Using a tool called Robot Framework, developers can remove the manual process and integrate it directly into the software development. Developers encode the test cases in the domain specific language, then run Robot Framework to execute these tests and produce test results.
Docs As Code
In a similar vein, documents are normally stored in word documents, shared drives, etc. Using a tool called AsciiDoctor, developers can integrate document outputs into the development process. Encode the text of the documents (software design, software requirements, version description, user manuals, etc.) in AsciiDoctor format, then running the tool to produce an HTML or PDF output.
Deploy As Code
The execution environment that the eventual product will be running under can be encoded in such a way to create a reproducible process from release to release. In addition, encode and tie the environment to the release itself, so as the code evolves, the environment evolves itself. Furthermore, this will allow developers to go back to previous versions of the software, they will have the build and the environment to run the code.
Build As Code
Gradle allows for the process steps to be encoded as build steps, this is the enabling factor for continuous integration and continuous delivery.
Key Takeaways
“As Code” is the key that can extend to other domains, including IT where it is popular. Tools like Ansible, Chef, and Puppet can take a description of what a particular machine should look like, in terms of services running/file structure/etc., run the description through the tools, and they perform those steps on the actual machine. The build is the process. Any steps the developer needs to take should be part of the build. Lastly, plain text is converted to a binary output via one of the tools created.