Agentless Release Automation is the new way of Managing Software Deployments

Many enterprise software systems can be categorized as either “Agent-based” or “Agent-less”. This blog is going to discuss why any organization would choose to select one method over the other, specifically around Release Automation and Software Deployments.

The first question one should pose – regardless of whether the potential solution is agent-less or not – is this, “What tasks am l looking to conduct as part of my Software Deployment solution?” At this point I also want to make it clear that when l am referring to “Software Deployments”, l am addressing the deployment of software across the end-to-end software development life cycle, not just production systems.

Without creating an exhaustive list that anticipates every granular task, required by every organization, for every software deployment scenario, I shall attempt to summarize the most common and typical steps and tasks:

  • Send artifacts to a remote server.
  • Manage and manipulate artifacts on a remote server.
  • Execute remote ‘jobs’ on a remote server – this can be categorized further as:
    • Execute a remote script that already resides on a remote server,
    • Send a script to the remote server and execute, and
    • Execute a system command on the remote server.
  • Compile source code on remote server.
  • Start / Stop Services on remote server.
  • Capture the results and output of a remote script or system command.

All things considered, the mechanisms employed around deploying software to remote servers is finite. Now that we understand what we need to manage a software deployment, we now need to assess the merits of whether or not to use an agent-based system.

To be blatantly clear, I would like to state now that my preference is firmly on the side of agent-less. This opinion is formed through many years of working with enterprise software – not just in the Release Automation space – and witnessing real-world limitations and challenges.


Disadvantages of an Agent-based Release Automation Solution

Agents are a great way of building robust connectivity between the deployment server and its end points – the remote servers to which one would like to deploy software and systems. However, any agent-less system could be deemed as robust if it is based on SSH/SSL secured connections.

In my opinion, the overheads associated with an agent-based solution far outweigh those of an agent-less solution.


Agent release automation Installation

Obvious, but crucial, an agent-based solution will require the customer to install agent software on each and every end point to which the customer is looking to deploy software and systems. In small companies this may not be a significant problem, but when dealing with large enterprises that might have hundreds, if not thousands, of end points then the resource requirements increase substantially.


Agent Configuration

Each and every agent will require configuration settings amended to ensure it can connect to the solution server. Each agent may also require configuration settings altered based on the role of the agent.



Agent Maintenance

Software vendors continually update and improve their solutions; an agent-based solution will, therefore, potentially require software updates. Again, not such a huge problem for small companies but large organizations will have to allocate resources for these upgrades, possibly initiating dedicated project teams to complete the upgrade effort.



Firewall & Relay Configuration

Agent-based systems will undoubtedly require firewall configuration changes to allow the agents and solution server to communicate and relay instructions and data between numerous domains within large corporate networks.



Agent Availability

Installing an agent will typically involve installing the agent software as a service running on the remote server. As with any service, it is possible that this service may ‘fail’, require configuration changes, need recycling, not be compatible with other services or, as a worst case scenario, require a complete re-installation.



Platform Support

Agents are a piece of software built for a specific platform; if you want to deploy to Windows then you will need a Windows agent, UNIX will require its specific agent, so too will Linux, and so on. Since it requires development resource for any vendor to build a specific agent, it is most cost effective for vendors to target the distributed platforms – Windows, UNIX and Linux.


However, large organizations make use of various platforms designed to address specific needs. Financial Services companies will make use of fault tolerant and high transaction processing platforms such as; iSeries, Stratus, OpenVMS and Tandem. Another example is Retail organizations that are likely to make use of the IBM4690 platform, for example. It is highly likely that these platforms are not supported by agent-based systems and prevent, therefore, organizations from achieving full Release Automation.




Advantages of an Agentless Release Automation Solution


Release Engineer (from OpenMake Software) is an agentless release automation solution. This means that all of the above agent-based disadvantages are addressed by removing the need for agents.


  • Agent Installation – Not Required
  • Agent Configuration – Not Applicable
  • Agent Maintenance – Not Applicable
  • Firewall & Relay Configuration – Most organizations will likely use SSH/SSL to connect and administer their server infrastructure, and since Release Engineer utilises the same protocol then no firewall changes will be necessary. Even if firewall changes are required, it’s no more effort than the agent-based solution and the connectivity configuration will be robust and secure.
  • Agent Availability – There is no reliance on the availability of any agents.
  • Platform Support – Since Release Engineer utilises standard protocols then the extent of the platforms to which Release Engineer can deploy is diverse, such as; Windows, UNIX, Linux, iSeries, OpenVMS, Tandem, Stratus, IBM4690, Tru64…


Ms. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that were common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

0 thoughts on “Agent-based or Agentless Release Automation Solution?”

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts


Release Packaging Vs. a Manifest File

Release Packaging better than a Manifest file/h1> Replace a Manifest File with Release Packaging Release packaging is the first thing you think about when you want to develop a process for executing a software deployment, Read more...


Continuous Delivery Vs. Application Release Automation

Continuous Delivery and Application Release Automation Understand the difference between application release automation and continuous delivery Application Release Automation is a set of tools while Continuous Delivery (CD) is a process. Continuous Delivery is an Read more...


Build Avoidance and Continuous Integration

Build Avoidance is a feature of Meister Build Avoidance a critical part of continuous integration In a recent article, the term “Build Avoidance” was referenced as if it was something new and improved.  NEWS Flash!  Read more...