In traditional development and deployment technologies, configuration information including security information was deployed to and persistently stored at systems on which one or more instances of one or more types of environments are to be run. Since these systems were potentially shared among different types of environments, users from the different environments may edit the source code of the configuration information that was shared, at least in part, among the different environments. However, problems arise when a user from a first type of environment edits the source code in a way that may detrimentally affect the configuration for a second type of environment.
Furthermore, writing a generic application that works for all environments is not easy. Some traditional approaches are error-prone. For example, one way is to edit “/etc/hosts” files to resolve hostname issues. This usually only works for advanced developers. An alternative approach is to put many if/else in the configuration information source code to differentiate the handling of different types of environment data. This approach creates a lot of code paths that will only execute in one type of environment, and makes testing/debugging in one type of environment (e.g., development) for issues from another type of environment (e.g., production) extremely difficult.