What does a modern software delivery process look like? As many different models exist as there are developers, this is one view...
Consider a group of different processes:
| Id | Task Overview | Note |
|---|---|---|
| 1 | Producing code | |
| 2 | Producing test cases | |
| 3 | Producing business requirements | |
| 4 | Producing documentation | |
| 5 | Producing the software that supports the code | Build scripts, deployment scripts |
| 6 | Supporting the hardware that supports the code | Desktops/laptops/switches/firewall |
| 7 | Design/product management | Deciding when, how and what to build |
| 8 | Implementation | Get the software working, build shims and adapters |
| 9 | Support | Keep clients happy |
Note that the above is referring to an old fashioned deployed software vendor or in-house build and deploy.
A SaaS/multi-tenant model looks different and we will cover that at a later date.
Just looking at two aspects today:
The anti-pattern that is the configuration file.
Packaging dependencies
The anti-pattern that is the configuration file...
Consider the typical deployment pattern of design-build-test-integrate-deploy. Yet changes to configuration files often slip outside of this cycle. While that may be convenient, it's a backdoor to delivering untested code paths to production.
Hence - package the configuration inside the .jar file and then force a code deployment for all changes to the process - whether it's a code change or a configuration change.
Packaging dependencies
So, Gradle can help remove these problems and make the deployment and support process more efficient. Hence why Gradle was used for the MQTT project and for other projects where we have provided technology consulting.
Other tools are available, your mileage might vary...
See also:
Comments
Post a Comment