Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Anti-Pattern: Fixing Configuration “As-Broken”

DZone's Guide to

Anti-Pattern: Fixing Configuration “As-Broken”

· DevOps Zone ·
Free Resource

Do you need to strengthen the security of the mobile apps you build? Discover more than 50 secure mobile development coding practices to make your apps more secure.

In the webinar Death to Manual Deployments we highlight a common problem in enterprise IT: configuration updates to middleware and applications are made on an “as-broken” basis. A developer will change the application to need a configuration tweak, which she makes on her own laptop. When the code is submitted a few days later the first test environment start showing errors. After a defect is raised, the developer informs QA of the change they need to make and its made. A week later, the application is promoted on to another testing environment where the application fails, defects are raised and eventually someone remembers to make the fix. Hopefully, someone gets this added to the release plan before the production release, but outage windows being extended due to this pattern is not unheard of.

The basic strategy to fix this challenge is to drive it into the release process as quickly as possible. Ideally the only way to make these kinds of configuration changes in any of your testing environments is through your deployment automation tool, such as UrbanCode Deploy. This will force the change to get captured, and make it easy to bind the configuration change with the application change that requires it. Otherwise, the policy should be that any kind of configuration change isn’t permitted unless it’s shown to be captured in the release plan. UrbanCode Release has a nice way of capturing these kinds of manual changes. Developers and testers are generally given  access to the lower environment deployment plan for the Release they are working on. Either the original programmer or the first tester to find the problem would update the plan with the instructions for making the configuration change. The new task would be flagged to run only in environments that hadn’t had the changed applied yet, and it would be suggested as a task to add to the production release plan. Easy to capture and easy to manage.

manual config change Anti Pattern: Fixing Configuration As Broken

 

Check out tips for blazing the way from agile to DevSecOps with security built into your mobile app toolchain.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}