Operational consideration
When we create code and infrastructure for development, it is in preparation for production.
Breaks in development workflow ultimately delay releases to production. So adequate testing of our code helps ensure that others working with us do not have bad experiences.
Continuity
Section titled “Continuity”Continuity of the development workflow is frequently underpinned by
- applying secure coding practices to ensure we are not leaking secure data or opening our applications to be exploited by bad actors
- adding feature tests to prove critical functionality is maintained
- employing health and ping checks to ensure availability in deployments
- creating anonymized test data that is functionally representative of that in live
The above headlines are not exhaustive and, depending on our use case, may well become longer.
This can be summarized as a ‘shift left’ of security and testing practice into early stages of the software development lifecycle.
Configuration
Section titled “Configuration”From infctl
’s pont of view, it creates for us a config.json
file at run time if not already present that contains :
{ "log_format": "<full|basic|none>", "deployment_file": "<path as specified to this pipeline file>", "deployment_type": "<development|pre-production|production where development is the default>", "deployment_mode": "json"}
So unless we edit this file, the default deployment_type
is that of development
.
It signifies that we have applied the above working practice.
Our code and pipelines can be documented, version controlled and checked from development through to production readiness.