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.
Strategies for working “over there”
Deploying software requires getting the software from where it is (an artifact repository) to where it will run in the target environment. Beyond file transfer, there may be additional installation and configuration steps. There are two basic strategies for executing the deployment. You can either have a worker on the deployment target (an agent) or not. Both strategies have the concept of a central deployment server that acts as a controller determining when and how deployments occur.
In an agentless deployment (see Figure 1), the central deployment server is responsible for connecting to the deployment targets and executing the deployment steps, or actions.
The deployment server must log into the target machined when the deployment actions are “on the box.”. On UNIX style-operating systems, SSH is typically used while tools like PSExec are may be used on Windows. Once logged in, the deployment server passes commands to the target machine for execution, may retrieve logs, and takes further action based on the responses. Continue reading