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

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

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

 

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Published at DZone with permission of Eric Minick, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}