UrbanCode Deploy (UCD) provides many source plugins that allow the UCD server to fetch new component versions from a variety of external repositories.
Some of these plugins, like the Jenkins one, are plugins for the 3rd party tool itself which allows Jenkins to push the new assets into UCD. While others like version the filesystem plugin are pull models because it requires UCD to actively go and look for new component versions.
The Pull Model
The pull model can be configured for either automatic or manual imports. In manual mode, as the name suggests UCD will go off and search for a new version of a component in the external repository that its configured to look in for that component. The request to look can be through the GUI or it could be triggered by an external script using the udclient importVersions command. The later can, in one command, request UCD to go and find new versions for multiple components. So you could use this in a build for example once you know all of the assets are available in the external repository.
In automatic mode, the UCD server will poll the repository at the interval defined in the servers’ system settings. The default for this in 5 minutes.
Whichever way you trigger a pull mode import, the UCD server will assign one or more agents, depending on where you are pulling from, to the task of importing the new files to create the new component versions.
The Push Model
In contrast, the push model is more immediate and involves using the udclient command line utility to programmatically create the new component version, upload the files for the version and optionally create an http link between the version and some other artefact.
The link would normally be used to preserve the traceability of the build into the deployment tool so that for a deployed version I can track back into say the build record and from there back into the change control system to see what changes were delivered in the version and so on back through development assets.
To do this, typically from my build script, I would perform the following steps for each for components that have been built. In this example, I’m going to create version 1.2 of my component JPetStore-WEB
udclient -username jsmith -password mypwd -weburl https://myucd:8443 createVersion -component JPetStore-WEB -name 1.2
udclient -username jsmith -password mypwd -weburl https://myucd:8443 addVersionFiles -component JPetStore-WEB -version 1.2 -base newcomponentVersionFolder
Optionally:
udclient -username jsmith -password mypwd -weburl https://myucd:8443 addVersionLink -component JPetStore-WEB -version 1.2 -linkName "Link to build result"
-link http://buildtool/buildresultID
The above commands have created a new component version container with the version identity 1.2 and then uploaded the files contained in the directory newcomponentVersionFolder into the new version container. Then optionally, I could create a link between the version and maybe the build record for the version. Or perhaps that link could be to a change record in your CM system detailing what changes are delivered by the new version.
Additionally, I could go further and add a UCD status to the version using udclient addVersionStatus or maybe set properties for the version using udclient setVersionProperty so I could perhaps turn on or note that debugging in this version is turned on.
Finally, I could at this point use the udclient again to request the deployment of the application containing that new version(s).
Best Approach?
If we were to compare the two models, it becomes apparent that each has its benefits but also weaknesses. In some cases, it may not be possible to use the push model as there is no triggering event available to kick off the push. For example, a 3rd party delivers a new version of some of your application components to you.
Personally, I prefer the push model whenever possible for the following reasons:
- No Agents involved
Whenever you use the pull model, an agent is involved and that means it consumes a license. This could be all that agent (or indeed agents) does, so it is consuming a license either full-time or for however long the session lasts + 30 minutes (the linger period).
- Immediate
If I push then I know when my version upload is complete. I can then immediately trigger a deploy into maybe a smoke-box environment where we do some automated tests and then create a snapshot ready to promote it to a dev deployment. If I pull, I don’t know when it completes. In fact, I don’t actually know when they will start. The agent might be busy importing parts of another application. All I do know is that I’m in the queue.
- Low Overhead
If I use the push model then I only do it when I know I have new component versions I definitely want to have ready for deployment. If my build fails, I won’t publish it. If I use the pull model configured for automatic import then the server will every few minutes reach out to your repository and find out if there are new versions of your component. For 99%+ of the time this is a wasted effort as there won’t be a new version. If you consider a large enterprise deployment of UCD, there might be 1000’s of components and if they were all configured for automatic input then the load on the server and your external repository would not be insignificant. Also, if using a single agent, the time taken to find new component versions might be quite lengthy.
- Risk of Partial Versions
With the pull model using automatic imports, you must consider if UCD can know with certainty that a new component version is complete, otherwise it might start importing before all the files are present. For example, if I’m using the versioned file system source plugin, I’d be well advised to stage the new component version directory somewhere else on the same file system and then move the directory into the area where UCD will look only when its complete. This move is then an atomic operation, so you will only get a complete version. Due to the nature of polling, most of the time you might get complete versions, but just occasionally you’ll be unlucky.
Summary
Personally, I always use the push model for the reasons outlined above. It streamlines my tool chain and allows me to deploy my complete application as quickly as possible after the build.
I can automate UCD from my build tool to upload just the files I want. I might simultaneously put the same assets into another repository for longer term permanent storage, but I can know with certainty when my versions are uploaded and available before kicking of the initial deploy into my first environment.
UCD Command line tool – udclient
If you have not yet discovered the udclient, you can download it from your server with this URL
http(s)://<<your server>>:<<server port>>/tools/udclient.zip
It’s a small java application so will require a supported JVM. You can find out everything you need to know about the udclient and the 100’s of UCD commands it supports here:
https://www.ibm.com/support/knowledgecenter/en/SS4GSP_7.0.2/com.ibm.udeploy.reference.doc/topics/cli_ch.html
Be careful to select the version of the product you have installed since udclient’s capabilities change with some new versions.
#urbancodedeploy #UrbanCode
#UrbanCodeDeploy