How can developers adopt an automation lead mindset
- Hector Flores
- Aug 24, 2021
- 4 min read
Automation is everything in a modern DevOps culture
Automated Builds
Automated Deployments
Automated Feedback
Automated Approvals...
Automated ...
The challenge arises when developers have trouble designing code that is Automatable
See the following situation:
Stakeholders create a new requirement
New requirement involves needing a payment system
Developer receives the requirement
The developer starts on creating all the needed components to process payments like a payment processing provider.
Developer pushes code into the repo
Marks the task "Complete"
Developer does a demo of the new payment system end of the sprint
The client is very happy and is excited to start testing
The developer mentions the next step is to "Operationalize" it to be used..... Which is a fancy word for "Didn't include DevOps automation work into the estimation of the requirement"
Now to most, this is not really a problem. Today we are seeing large gaps between DevOps and Developers when this is completely against DevOps culture. DevOps is literally the manner in which we "Develop + Operate" a product in an integrated manner. Therefore, having a classic mindset of operating after developing goes aginst the shift left mentality
Here are some areas where developers can start to include an automation lead mindset into their normal workflows.
1 - App Settings are your friend
Being able to configure an environment is critical when deploying into different gates or phases. A good example would be the payment feature above. It's obvious that in development, a "Mock" of the payment service provider is needed. While in production, we want to use a live service provider that actually makes real charges to a client's card.
To make a new feature Automatable it first needs to be Configurable
To do this developers can follow the following rules:
Anytime a "value" of any sort is needed. Use an app setting with a default value
Anytime there is a "secret" of any sort. Make it a "Consumable secret" and add the default.
Never leave critical app settings with defaults. Force DevOps to fill it in with error-raising code.
Example: The name of a storage account to use for file storage. We never really want a storage account to default since if we get to production and no one has remembered to override it, you will have production data going into a non-production environment.
2 - Feature flags make you shine
This article will not cover different ways of implementing feature flags in a solution since that is out of scope. The article will assume feature flags are implemented in a basic form (In the form of an app setting).
Feature flags are a great way to provide hooks or options for DevOps to turn on or turn off certain ways an application operates. This is especially important in production scenarios. In many cases when the code reaches higher environments and there are issues that need to have workaround immediately, making code changes late in the game may come at a cost. To prevent this, if feature flags are implemented early in the development process, they can be used to deescalate incidents making the developers feature shine Feature flags are also a great way to give control to the client. When a feature should be enabled for any particular reason a client can make that decision. A good example is when a feature is only enabled in a "load testing" environment.
To make a new feature Automatable it first needs to be Togglable
To do this developers can follow the following rules:
Any new critical path is added, add a feature flag around it.
This can be in the form of a simple app setting "DisablePaymentService" default is "false". Wrap the code that does payments with an if and done...
Keep a document on all the feature flags, their defaults, possible values, and impact
This can be as simple as a "MarkDown" file next to the code or as complex as a team structured wiki
3 - Don't forget about infrastructure-as-code
Infrastructure-as-code is what is needed to ensure an organization's infrastructure is reliably stood up. This is pretty hard to do for some organizations but is necessary for a product to be reliably created, resilient to possible incidents, and maintainable for future cloud infrastructure changes
Infrastructure is usually a "No go" for developers. They want nothing to do with it... It is better to have "Full-Stack Engineers" instead of "Full-Stack Developers". Therefore, if a client's development team is missing the skill set to have knowledge of infrastructure then we need to start motivating communication and team strategies to close the gap between developers and infrastructure.
To make a new feature Automatable it first needs to be Provisionable
To do this developers can follow the following rules:
Any new cloud resource that is needed. ---> Ensure very close team collaboration is held on the need for the resource
Any updates needed to a cloud resource ---> Ensure very close team collaboration is held on the updates needed for the resource
Always strive to grow to be a "Full-Stack Engineer" not a "Full-Stack Developer"
4 - Think of production to cover the rest
In general, what is listed above are mainly the areas where developers can close the gap. In some cases, there are situations that don't fall in any of these areas.
The best way to be proactive in covering those areas that are in need of automation is to think "How will this look in production". Asking that question will instigate a different part of the brain to fire and will give the answer every time
To make a new feature Automatable it first needs to be Production Ready
To do this developers can follow the following rules:
For any new feature or workflow ask yourself the question. "What does this look like in production?" Find what is needed and move forward with including in tasking
Keep informed on the higher up plan for a production delivery to ensure any new features don't clash with existing plans
Conclusion:
In the past being a "Full-Stack Developer" was the buzzword. Slowly the new buzz role will be "Full-Stack Engineer". As a development community, we need to keep progressing in our growth since the industry moves fast. Soon the era of engineers will arise. Developers need to adapt if they are to survive.
Comments