The IBM WebSphere Application Server – Configure plug-in was designed to manage configuration at either the Cell, Node, Server, or Cluster scope. This means the entire configuration at the Cell, Node, Server, or Cluster scope is stored in an UrbanCode Deploy component. For example, the configuration of a single application server may be stored in a component inside UrbanCode Deploy. Benefits of the approach include:

• Easily promote your configuration across environments. For example, if the configuration of an application server is managed in an UrbanCode Deploy component, you may easily apply it to your test environment, then your production environment, and be confident that the configuration is correct and consistent.
• Treat your configuration as code. Since your configuration is stored in one or more JSON files, you may place the files under source control and version them. Configuration changes should be made to the code, not through the WAS admin console. Not only does this track configuration changes over time, but it allows you to…
• Easily roll-back your configuration. A roll-back is as simple as applying a previous version of your configuration.
• Easily determine differences in your configuration. If version A of your configuration worked perfectly, but version B is having problems, compare version A of your configuration to version B and see the exact differences of the configuration.
• Configuration Drift Detection. Let’s say something goes wrong in your WAS environment in the middle of the night. An admin changes some settings using the WAS admin console to get things working. What exactly did they change? UrbanCode Deploy can detect which changes were made. You may even do things like run a process every night to ensure your configuration in WAS matches the expected configuration in UrbanCode Deploy.

Drawbacks of this approach include…

• Applying configuration may feel slow. Because the plug-in is managing your configuration at an entire score, a small configuration change may take multiple minutes to complete. This is because the plug-in is checking the entire configuration against what is in WAS to ensure the configuration is applied 100% correctly.
• Managing the entire configuration at a scope may not be desired by some users. If you are certain in the consistency of your WAS environments, you may not be interested in managing the entire configuration.

Because of the benefits listed above, we strongly encourage users to manage their configuration at the Cell, Node, Server, and Cluster scopes. To help manage the configuration, and to make changes to the configuration, view the topics on using configuration snippets such as this overview. Some users have expressed the drawbacks outweigh the benefits of the approach described above in their case. To alleviate their concerns, the Partial Apply and Partial Remove steps were added to the plug-in. These steps typically apply or remove specific configuration objects while ignoring the rest of the configuration. Benefits of using Partial Apply/Remove include:

• Configuration changes are made quickly since most of the configuration is being ignored.
• Less configuration to manage since some configuration is being ignored.

Drawbacks to using Partial Apply/Remove include:

• Difficult to track configuration changes over time. It may be difficult or impossible to determine what exactly your configuration was, say, two months ago.
• Lose the ability to perform configuration drift. Without knowing the entire configuration at a Cell, Node, Server, or Cluster scope, UrbanCode Deploy will be unable to determine configuration differences.
• You may not be 100% confident that your expected configuration matches your actual configuration. For example, if you are using Partial Apply steps to create JDBCProviders, but someone else added some unrelated but required custom properties in your environment, UrbanCode Deploy would be unaware of those custom properties.
• Promoting configuration across environments may bring uncertainty. UrbanCode Deploy by itself will not be able to guarantee what is in your, say, test environment matches your production environment if you are not managing the entire configuration.
• Partial Apply/Remove is not much different than running various wsadmin scripts. In fact, those scripts may execute even faster.
• Limited number of configuration objects supported by Partial Apply/Remove. It may not be possible to use Partial Apply/Remove on every configuration object you want.

Again, we encourage users to avoid using the Partial Apply/Remove steps and instead manage configuration at the Cell/Node/Server/Cluster scope, as we feel you will gain the most benefit from UrbanCode Deploy with that approach. Of course, the Partial Apply/Remove steps may be desired for your situation. Please weigh the pros and cons of both approaches to determine what works best for you.