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
Have you ever been so frustrated with your release plan that you wanted to destroy it? Even well documented release plans can be burdensome because the entire release is not visible in a single view.
The release Pipeline view in IBM UrbanCode Release 6.0.1 provides a visual representation of the entire release and includes, the phases, environments associated, the applications and their versions.
Figure 0‑1 | Pipeline view in IBM UrbanCode Release
In the release pipeline view, you can:
- View a previously scheduled deployment to see if it passed or failed as well as view details into the applications, the application’s versions, the applications’ status, and any gates associated with that version.
- View the next scheduled application deployment and its status
- Compare multiple versions of applications based on component names, version number, and status of the application.
- Create a snapshot (release version) of the desired inventory for the set of applications and their versions in the release. You can schedule the deployment of this release version to subsequent environments.
- And more!
Learn more about IBM UrbanCode Release here. And tell us, what is your biggest gripe about release planning?
Coming off the successful introduction of IBM UrbanCode Deploy 6.0 and IBM UrbanCode Release 6.0 in September, we are pleased to announce a set of new features and functionality for both solutions in their 6.0.1 releases.
Some of the new capabilities in UrbanCode Deploy are:
- Tagging applications, components, agents, and resources to ease in grouping, navigating, and organizing complex applications and environments
- Expanded z/OS support using Rexx scripts to extend deployable target environments of your multi-tier applications
- WebSphere Portal as a target deployment platform
- Enhanced WebSphere Application Server support
In UrbanCode Release you can now:
- See precisely what is deployed across every environment and application in a release, compare environment content, and promote changes from one environment to another in a single view
- View real-time progress of a major software release event, when multiple business units are contributing to a single, enterprise release spanning hundreds of applications
More detail on a few of these features will be available in later posts. In the meantime, you can read more about the release here.
Lara Ziosi has started a great series on extending IBM UrbanCode Deploy with two articles. One providing an introduction to using the command line interface (CLI) from within Groovy. The other shows how to use the REST interface using Apache Wink.
I have to say that the outpouring of great material like this from our new colleagues is one of the many pleasant surprises that has made joining the IBM family a whole lot of fun for the UrbanCode crew.
Lara’s blog is here: http://devblog.laraziosi.org/extensibility/
Here are the direct links to the two articles:
Getting started with the IBM UrbanCode Deploy REST API using Apache Wink
Getting started with the IBM UrbanCode Deploy CLI using Groovy
The #NoProjects meme is catching hold, mostly as a rejection of forming project teams. I’ll be posting more on the “No” meme’s in the coming days. Meanwhile I’m intrigued by the ideas put forth by Carmen DeArdo of Nationwide Insurance during a webcast on DevOps on Tuesday.
Carmen suggests that forming teams of developers for each project, and tearing them down afterwards was acting as a barrier to adopting agile practices. Much of the learning belonged to the team that had learned how to work together with agility. To support an Agile transformation, they wanted to keep their developers together. They stopped putting developers on project teams, and formed application development teams. Those sympathetic to #NoProjects will be pleased, including myself.
However, as Carmen explains in the Q&A, they still have “Projects” that are delivering capabilities that span many applications. A small project team is formed (mostly of project manager types) that works with the application development teams. It sounds like Developers live with their applications, and PMs translate business initiatives to changes in many applications. A promising matrix approach.
This was by no means the focus of the talk, and I may have some details wrong, but I find the approach very interesting. Ok, #NoProjects people, tell me what you think of this approach (which may or may not be what Nationwide is actually doing).
You should check out Carmen’s whole presentation here.