Distributed environments, central control
Opereto deployment comprises a central control center (A cloud based virtual appliance server/cluster) and one or more remote agents. Opereto agents are simple, lightweight Java executables that retrieve process requests from the center, execute them on the device or host they reside and send all execution logs back to the center. Agents listen to Opereto center directives via secured and authenticated HTTPS. Based on this approach, there is no need to handle firewall policies or network configurations, a simple internet connectivity is all needed, thus, agents can quickly and securely connect to Opereto center anywhere, anytime.
Automation shared and reusable services
Utilizing a collaborative automation approach, Opereto enables Developers, QA, Customer Success and DevOps engineers to wrap existing or new automation components (tools, scripts, interfaces..) as shared and reusable services. Services in Opereto can either be:
- Self-contained executable software programs that Opereto runs on remote agents
- YAML schemes that are compiled and executed by Opereto control center (see cycle / test plan bellow)
Once created and uploaded to Opereto, developers and users can manage and run automation services using Opereto REST API or via Opereto UI Dashboard. Opereto provides a versioning control mechanism to manage service versions and a sandbox mode allowing developers to maintain, deploy and run custom versions of automation services and service flows.
Any automation activity can be a service. For example:
OS service actions:
Opereto allows to manage test environments dynamically. It provides a set of pre-defined service packages, schemes and API calls for developers to use in order to build custom setup and teardown services (or wrap existing provisioning tools they already use). On-demand environment services are uses by Opereto cycles and test plan mechanism to orchestrate a complete regression system test of new release candidates. However, it is commonly used also by QA manual tester, customer success engineers and other technical members using Opereto UI to manage private instances of test environments for testing, debugging or training purposes.
As mentioned earlier, agents are installed on remote hosts or devices and run services assigned to them by Opereto center. They are the execution endpoints. Test environments may include agents enabling to run test actions within the agent hosts. For instance, to perform a CPU measure, stop and start OS services, reboot a host instance Etc. However, Often, in continuous testing deployment, many and sometimes even all of the system test operations do not need to run directly on the test environment endpoints and could be operated from another endpoint that is external to the SUT test environment.
Some examples for test operations that are performed outside of the test environment:
- Testing the SUT via its public APIs (e.g. REST or UI) using external clients w/o the need to run anything on the application endpoints (e.g. vms, containers etc)
- Setup/teardown test environments, for example, a process that creates a K8s cluster or the SUT application in GCP via its API
- Wrapper to tests tools or client that communicate with SUT (e.g. jMeter, Selenium, TestCafe, REST clients..)
Opereto allows tagging agents as custom workers and also tag specific services to run only on those workers. This way, it guarantees that a particular service will only run on specific agents. For example, it enables to map test flow services to run on dedicated execution workers while mapping test operations to run on the relevant test environment's internal agent. Services-agents mapping is essential for scaling too. Using agent tags, one can create a cluster of workers for tools, test flows, and other operational services. Opereto provides an official open-source worker and a set of out-of-the-box services running on it (e.g. generic test tools wrappers, container tools, cloud provisioning tool wrappers Etc). Opereto developers may easily extend that worker functionality adding more services running on it or they can build their own custom workers executing custom services.
Workflows in code
Custom workflows in Opereto are written in code and deployed as services. It is extremely useful to write a distributed and complex system test flows in code. Unlike configuration management or IT provisioning tools that that are more simple to structure and thus, use of DSL-based schemes does make sense, system tests require more programming strength like advances conditions flows, loops, exception handling and other mechanisms that modern programming languages offer. The orchestration is made by communicating with the Opereto cluster via REST which makes it very flexible and accessible from any programming language. A developer can start and terminate processes on any of the distributed agents, run them in parallel or sequentially, track process statuses, parse process outputs, run complex log search patterns Etc. from a single short script written in his/her favourite programming language and IDE tools.
Automation Test Plans