Develop for Environment Specific Configuration

There is a pattern I see often among junior/associate developers when it comes to handling environment-specific configuration. The observed pattern could be summarized as junior developers creating separate fields for development and production environments in the application, misunderstanding the need for a single environment-aware configuration, resulting in duplicated logic to handle different keys based on the environment.

An example of this in action is there will be a request to add a field in the admin area of a website to store a key for some purpose. We would typically have a dev key and a production key so depending on the environment we would use the appropriate key. The junior developer might see this and understand the request to be: “Create two fields in the admin, one for each environment”. After which they also add logic into the code base to check which environment the application is running and read the correct key. I was not clear at first about how to explain this, but I see now it comes down to understanding, or maybe not understanding environment-specific configuration. Understanding that we have multiple versions of the application (development and production), each with its databases, and so we just need to define the configuration once, in each version of the app.

It’s come up enough that I want to call it out, to help people on the path to thinking like a software engineer.

When thinking about environment-specific configuration there are some good practices to remember:

• Configuration Files: Use separate configuration files for each environment (dev, prod, etc.), allowing easy management and modification of settings.
• Environment Variables: Leverage environment variables to store sensitive or environment-specific information, enhancing security and flexibility.
• Single Source of Truth: Maintain a single configuration source to avoid duplication and inconsistency. Centralize configuration management for better control.
• Parameterization: Parameterize your application to make it adaptable to different environments. Avoid hardcoding values that might change between setups.
• Automated Deployment: Implement automated deployment processes to ensure consistency across environments, reducing the chances of configuration errors.
• Version Control: Store configuration files in version control systems to track changes and easily roll back if needed.
• Documentation: Document the configuration settings clearly, specifying their purpose and acceptable values. This aids understanding and future maintenance.
• Secure Configuration: Separate sensitive information (like API keys or database passwords) from the codebase and manage them securely, possibly using vaults or secure storage solutions.
• Testing Environments: Mimic production environments as closely as possible in testing setups to catch potential issues related to environment-specific configurations early.
• Continuous Integration: Integrate configuration checks into your continuous integration process to identify any issues before deployment.