The last new feature from the v6.0.1 releases is IBM UrbanCode Release’s new impact analysis capability. Release Managers constantly struggle with interconnected applications and the threat that when some applications miss the window, others will have to be held back. The idea of the new view is to visualize the relationship between:
- Changes (bug fixes, new features, etc)
- Development Initiatives (projects, epics, etc)
- Applications in a Release
In this view, we can see the Applications in the small Release as the rows, and the development initiatives as the columns. The number of changes associated with their combination is shown along with a color code indication of how done the features are.
At a glance, we can see that no Initiatives span multiple applications. So if any Applications have to drop out of the release, the others should be relatively safe. If other Applications were participating in Initiative 1 or 4, the amount of in progress work would be worrisome.
This new impact analysis view is available from the Release overview screen.
There are three updates to the process designer in UrbanCode Deploy v6.0.1.
1. For-Each Containers
Application process govern the order and counts of component processes. Sometimes you want to run a number of processes from various components together. For instance, you may want to take a web server out of the load balancer, run the installs for several web apps, and kick off tests against that server before putting it back in. That process across various web app and testing components would then be looped over for each server. The process designer now makes it easy to define those kinds of activities.
2) Multi-component steps
Application processes can now have a single step that runs a process against all of the applications components that have a process with that name. So if you want to run the “Deploy WARs” process against all of your web apps at the same time, you can drop in a single step to handle that. Using the naming conventions works particularly nicely in conjunction with component templates – if all your components of a type are inheriting from the same base template, they will all have processes with the same name. Teams that have large numbers of similar components that get deployed together find this especially handy. They can add a new component to an Application and it will deploy fine without having to update the deployment process to accommodate it.
The final feature is the most simple. If you need to explain what some portions of your process is doing, the new notes functionality makes it easy to annotate the workflow diagram with additional commentary.
Properties are a big deal. They help us parameterize things so that a process works on various targets or environment or versions. Ever forget the capitalization used in the property name? Or its scope? Or whether words were separated by a dash or period?
Of course you haven’t had that problem, but people like me are forgetful. After intensely lobbying the developers, they helped me out and added some auto-complete / suggestion magic when you start referencing a property. So nice.
Life just got a little easier.
For an overview of the 6.0.1 release go here. This is the third of a series of looks at specific features in a surprisingly big “dot one” release.
What was in QA last week? Answering that question used to take a bit of snooping around. You would basically look at the history of deployments into QA and could reverse engineer the state at any time.
The IBM UrbanCode Team thought that the tool could do that work for you and provide a clear historical view of what versions of any component where in which application environments when. It looks like this:
This view can always provide some insights into how versions tend to flow through environments. Altogether less work than piecing it together yourself.
For an overview of the 6.0.1 release go here. This is the second of a series of looks at specific features in a surprisingly big “dot one” release.
A big focus in IBM UrbanCode Deploy is keeping track of what is where. Our clients love to compare various elements and we are regularly adding more comparisons views. 6.0.1 brings the latest batch of new view.
When comparing environments or snapshots, it’s now easier to view differences in properties at various scopes. The deeper property comparisons extends to deployment previews as well. It’ll now show which properties on which resources (deployment targets) will be updated as part of the deployment.
Finally, we’ve taken the environment level File comparison to the next level. While it’s identified which files changed in the past, UrbanCode Deploy will now provide a graphical diff for text files.
Visibility into changes is always a good thing, and we’re happy to keep adding more views. Let us know what else you would like to see!
For an overview of the 6.0.1 release go here. This is the first of a series of looks at specific features in a surprisingly big “dot one” release.
We’re excited that now the “source configs” that define how IBM UrbanCode Deploy discovers and imports files to deploy are now plugins just like automation steps. The easy wins are the standard plugin benefits. New versions of the integrations can be loaded without upgrading the application or restarting and our customers can create their own source types.