Own Deployment Automation
Cut out major headaches when developing, deploying, and automating software.
Automate Deployment
Cut out major headaches when developing, deploying, and automating software. Our experience within enterprises and substantial work on our data platforms highlighted a major shortcoming - more time can be spent deploying, test, and automating software, than developing it. Defining requirements, testing, deploying, and running software is a hugely underestimated part of the Software Development Lifecycle (SDLC). We tend to imagine that we want some software, pay for it, and our needs are answered. Our IRPA software focuses on a simple concept - Deployment and Execution are one and the same.
Most development focuses on; Developing the application. Configuring the application for a test/higher environment. Testing the application. Building a batch. Passing the application to a devops/application team who; deploys the software manually, reviews log books, asks developers to hand-hold the deployment team through the process.
Developers, exasperated with this process resolve to eliminate this waste. They procure Continuous Integration solutions to dramatically speed up this process. Whilst excellent, the time taken to set up CI configuration is lengthy and has a fairly lengthy learning curve. Our specific problem was being able to develop, automate, and add new functionality without spending vast amounts of time away from development. Larger organisations have at least 5 or 6 teams fully committed to this SDLC. This makes any organisation working on the same product in a different way.
Developers
- Want to write software
- Aren't keen on building batches
- Should not be spending time with each team to steer their work into production
- Want better feedback on integration testing
Test Analysts
- Tend not to be as accomplished on automation software
- Often want to run things themselves
- Want to focus more on testing
- Are challenged by availability of test data
DevOps
- Don't want to spend their time applying configuration across environments
- Are challenged by data availability when automating processes
- Want to automate deployments
- Seek to avoid manual tasks from written instructions
Info Rhino Process Automation to the rescue
Info Rhino Process Automation (IRPA) addresses one key issue;
Duplication of effort must be kept to a minimum
Understanding Info Rhino Process Automation
Where does IRPA fits in?
IRPA can be the platform to be the enterprise level software for process automation, release management, and deployment management. We don't attempt to make that claim because there are so many different ways to achieve similar objectives.
We use IRPA for all of our Deployment Automation and batch processing. However, many organisations just want to get things up and running quickly, avoid yet another system to train and maintain staff on. IRPA is raw management, and whilst we are to add user interface to this platform, we are focused more on interpreting environments - reporting that, than adding user interfaces.
Some may wish to use IRPA until their organisation grows to a point where Enterprise solutions are needed. Others may see IRPA slots in between existing architectures to get processes and deployments to test environments faster. Some may use it in Production and still use traditional Enterprise Solutions.
The IRPA openness philosophy
Those who work with IRPA will see that we focus on openness. Whilst there is specific application logic, our applications reveal their intentions in files and databases. This simple approach gives our clients two key advantages;
- They can use their own software to generate these files and drop them into our IRPA.
- They can take our data objects and write their own applications to work with these structures.
We start to see that IRPA doesn't always have a beginning or end, or a set of rules. Indeed, IRPA can discover IRPA, which can have been generated by IRPA.
We have batches which discovers batches. In other situations, we write template batch files, which can be published to different environments, and then discovered by subsequent IRPA processes for automation.
We see discovery and understanding above slick user interfaces and are thus likely to add more advanced reporting to make it easier for teams to understand their enterprise application architecture.
How does IRPA work?
Deployment Application
Our Deployment application has 10 operating modes. These modes serve to aid managing and moving configuration and applications. The application can execute processes and can generate files from templates. Publication mode controls deploying application and environmental artefacts to bring control to any deployment. Whilst setting up any deployment automation is a complicated affair, our Deployment Application simplifies this process and reduces time spent on the configuration management.
Process Automation
Our Deployment application has 10 operating modes. These modes serve to aid managing and moving configuration and applications. The application can execute processes and can generate files from templates. Publication mode controls deploying application and environmental artefacts to bring control to any deployment. Whilst setting up any deployment automation is a complicated affair, our Deployment Application simplifies this process and reduces time spent on the configuration management.
Release Versioning
A very common scenario in organisations is to develop software, package it, and deploy it to be part of a batch process or chain of events. This requirement is nothing new. However, we found most batch management software too expensive, and too clunky to consider. Our Processor software is a simple application which generates job definitions and executes them. A key benefit is defining a single application, to discover instances. We can set the degree of parallelisation to have 100 instances, which run 5 at a time, but only set up one job definition.
Raw Setup
Those who have worked with Process Automation and Continuous Integration software come to realise that these operations becomes more about the framework application than the process. More simply, we have to do our deployments their way, not our way. We, for example, see nothing wrong in adding xcopy to a batch file to move some files over despite our software having that capability within it. This paradigm shift gives us more freedom to focus on the task at hand.