I finally made the switch to version 4.0 of the Software Factory. I’ve been working on this goal for a very long time. It feels like I’ve been working towards this forever. And, it’s finally here…
It’s like getting a new car; I can see all the trips I can take with it, all the new things that are now possible. This release opens up a whole new set of opportunities.
Here are some of the features that I can now leverage:
One of the most significant features of this version is the ability to “easily” create new model types. This means I can build new inputs for the Software Factory to describe: Data structures, services, applications, or even entire systems.
I have already created a new model to describe model types. This way, I can model the model types (that is a mouthful…) using the client application and then generate everything the SF needs to use new model types, including client libraries.
This means I can go ahead with the great Reboot and start over with brand new model types. The goal is to move away from the monolithic structures I have been using so far and move towards smaller and more modular components.
Then, I will be able to build real engineered solutions rather than keep on hacking together and working around stuff.
I created a new set of client applications for managing all the Software Factory data. While they are not all feature complete, I would classify them more as Minimal Viable Products; they replace a set of tools that were not always viable.
Now I can manage the different aspects of the Software Factory with ease and confidence. This allows me to build new capabilities into the system much faster.
In addition, the new client applications are much easier to modify. I can add features easily and deploy them in minutes.
The architecture for the new clients is much better than before. So, they will also serve as a strong foundation for functional templates for future code generation.
Improved result management
To keep track of what is happening inside, the Software Factory generates a massive amount of data. Every time I run a build, in addition to the generated code, it generates a lot of data that describe what is happening during the generation process.
Previously, the results were just pushed into a database, and I would end up with the results of thousands of generation requests. Most of the requests were made obsolete by the one following them, but this data accumulated into millions of records that no longer served a purpose.
I introduced an explicit Request / Result system that keeps track of when requests are created or deleted. With the new version, when requests are deleted, the corresponding results are automatically removed. A request lifetime service was also introduced so I can eventually automatically remove information that is no longer relevant and keep valuable information.
In addition, the generated code is now pushed directly into a git repository. This way, I have access to a history of the evolution of the generated code.
While this is not a feature in itself, it makes building and deploying the different components of the Sofware Factory a LOT easier. I can now make changes to any components, including the code generation engine, and deploy it in minutes.
Before deploying, some of the components required some pretty involved and error-prone procedures. Now, I just change the image version in the configuration, and new containers are automatically spawned in my Kubernetes cluster.
This also means I can deploy this anywhere, not just on my development machine, as in prior versions.
This allows me to move into a new phase. I no longer have to put all my efforts into building the Sofware Factory. I can now realize the vision:
Specify the desired behavior, and the program will write the code. Entire product lines could be constructed that way. Massive amounts of flawless code at the click of a button.