Continuous Deployment
Problem
Complex deployment process that is difficult to automate: many components with different configuration have to be deployed to different target environments such as staging, test and production environments. High effort for manual deployments.
Solution
Visual modelling of software creates one place to keep an overview over deployments. Model is used as basis for end-to-end automation in Python automation engine. Modular automation makes changes to the deployment automation a breeze.
The problem
Automatic deployment of software that consists of many components and/or is intended to be delivered in many different configurations to a wide variety of target systems is challenging. Do you know some of these problems?
- Since the software is actively under development, the deployment process changes frequently. Therefore, there is hardly any investment in automation because the effort required to constantly adapt the automation is too high.
- Manual deployment is very time-consuming. Changes in the software and the deployment process often lead to errors that take time to analyze and resolve.
- The deployment process (and the software itself) is hardly documented. Information about changes that need to be taken into account during deployment is not always reliably passed on internally.
- Attempts to automate the deployment with classic deployment tools or self-developed scripts were time-consuming and did not improve the situation.
- Introducing deployment automation would be a change that affects multiple teams and departments. Getting everyone on board and implementing such a change is difficult.
- There are no internal resources available to deal with deployment automation.
The solution: continuous deployment tool from Cloudomation
Modelling and end-to-end automation of the deplyoment process with Cloudomation Engine:
- The Cloudomation platform allows easy modeling of the software, components and their dependencies. The modeling serves as a target state description for the underlying automation.
- The automation of the deployment process is implemented in Python. In Python, complex and nested conditions can be easily mapped and any deployment logic can be automated.
- By visually representing the software and the deployment process, the deployment process becomes tangible and understandable.
- Modular automation in defined individual steps makes changes to deployment automation easy.
- Existing scripts and automations in other tools can be integrated and reused.
- With affordable entry-level packages and flexible pricing, you can test deployment automation in a small team and gradually roll it out throughout the wider organization.
- Our team is at your disposal throughout the entire process: develop your automations yourself, together with us, or commission us to carry out the entire implementation – just as you wish.
- Automations remain lean, maintainable and clear
How it works
Visual modeling of your software as a basis for your automation: Describe your software. Use the model in deployment automation. Keep track of things.
Pro-code automation: This allows unprecedented flexibility with no predefined data model and no limits to express complexity.
Lean, fast, customer-centric: Lightweight platform, focus on customer enablement, customer-centric product development.
The result
Modeling your software provides an overview and basis for deployment automation:
- Since the model is used for automation, it always remains up to date
- Model templates enable a quick start
Flexible automation that grows with the user:
- Tailored to your requirements: As simple as possible, as complex as necessary
- Adding, removing and changing release variants is quick and easy
- Graphical representation of the process also tangible for non-technicians
- Traceability for all process steps
FAQ
A deployment target is a location where software is installed – this can be a single server, but it can also be multiple servers or VMs. There is no limit on the number of deployment targets that can be automated with Cloudomation Engine.
Yes, a component can be deployed to multiple different servers. Multiple components can also be deployed on a single server, or a component can be deployed on its own server while others are deployed on shared ones, etc. How and where the software is deployed is fully customizable.
No agents need to be pre-installed on the deployment targets. For example, Cloudomation can connect to a server agentlessly via SSH to install software. Cloudomation can also directly interact with APIs of cloud providers or virtualization technologies to create the infrastructure on which the software is then installed.
Any error-catching logic can be implemented. By default, all connectors pass on errors they encounter, allowing you to define in the Python logic within Cloudomation Engine how to handle these errors. You can also use general error-handling logic that defines how to proceed independently of specific errors (for instance, when it is not known which errors might occur), such as sending notifications.
Logs are stored on the Cloudomation server. There is a log expiry logic that can be customized. Generally, we recommend deleting older logs from the Cloudomation server. A log archiving logic can be implemented to write logs to a log server or an archive.
There are no inherent limits on the software side, but performance heavily depends on the volume and size of the data being transferred. Depending on the amount of data to be transferred, the Cloudomation server may also need to be appropriately “sized”.