What is otto windows

oTTo — the best kind of automation is oTTomotation

oTTo-what-now?!

oTTo was born out of a need for a quick and simple web automation framework for a small project. As the project grew, so did oTTo. It quickly took on a much more coherent form and started to look more complete than the loose gathering of tools hanging off a framework.

There were lots of things that were found along the way, lots of help and hints and tips given and the hope is that by putting this here, others might be able to use it to quickly get something setup for their own purposes and/or get a nice introduction to automation tools and some of the usage. There are READMEs along the way that should explain the basics and a general usage guide that should mean you can get up and running pretty quickly.

oTTo does assume a basic knowledge of Ruby, however this is not difficult to pick up for newcomers and the community is very helpful. Remember, no question is a stupid question! There are also some cheatsheets included with oTTo which might come in handy.

Some of the tech used in oTTo

Some of the main tech used under the hood

Installation

oTTo is currently only optomised for use on MAC OSX so might not function as intended on Windows machines (and the install will be different) but this is something that is high on the list of issues to address

Mac OSX

Automatic Installation

Whilst the automatic install is very useful. NEVER INSTALL A RANDOM SCRIPT FROM ANYWHERE! READ THE setup_script FILE BEFORE DOING ANYTHING

To automatically install all components for oTTo

Manual Installation

You will need to get the specified version of Ruby (currently v2.6.0) as well as installing RVM for Ruby version management.

You will also need to install all the additional RubyGems listed in the Gemfile using the bundler gem built in to Ruby. This will generate a Gemfile.lock and this will set all the Gem versions for your project. Do not delete this unless you plan to update.

Ensure you have Homebrew installed by checking

If you do not have a valid version of Homebrew then you will need to install it. There are excellent instructions for installation on their webpage so no need to reproduce here.

You might need to also install some drivers for Selenium to use

If an alternate version of Ruby is installed (Mojave comes with Ruby 2.5.1 pre bundled for example) then you may need to uninstall this before use using. Check the versions of Ruby installed using

and if you have anything other than than version you installed in the setup above

You will also need to ensure that you have installed Cucumber Standalone JSON Formatter as per their instructions on the Github page

If you do not install this correctly then you will fall into trouble with the reporting element of this tool.

For adding to your PATH , this page may be of some help

Basic Usage

The basic usage of oTTo is running a single script, scripts/test.sh . This is a bash script and is run from the home directory using

This will take configuration options passed in by the user and use them to run the specified BDD features.

To see how to configure the script check out the README which goes into detail about each part of the script and what it is used for.

The script runs several tasks from the Rakefile including the test , rerun and report tasks. All of these can be run in isolation if needed/wanted using the command

This task is responsible for actually running the testing. It is constructed using Rake syntax for a Cucumber command

It uses the test.sh script to construct a Cucumber syntax command. The options are the specific tags to be run and the default text is to output a json file of results used by the report builder as well as a text file designed to keep track of failed test items. This constructs and runs the command

Alternative Cucumber commands can be added to this file in this format if you wish to.

This is very similar to rake test however, as you would expect, it runs the failed tests from the initial run. It requires you to have already run rake test , or at least have a rerun.txt file available with failures listed, as this is where it draws from instead of Cucumber tags. It constructs and runs the command

This is a very simple rake task that simply runs the script ‘./lib/report_builder.rb’ (which you will notice is defined at the top of the file)

This generates an easy to read html report (see the lib README for more information)

Runs the unit tests (see the unit_tests README)

Credit where credit is due

oTTo could not have been put together without the help of many people along the way.

This isn’t complete or perfect but hey, nothing ever is! If you want to contribute to oTTo that would be great! Please do contribute in any way that makes this a better tool or teaching/learning aid 😊 All we ask is that you follow the normal kind of things, Code of Conduct and Contributing and then you can win a place on the coveted List of Contributors! («ooo, it’s so shiny!»)

About

oTTo — the best kind of automation is oTTomotation

What is otto windows

Meet Otto, your friendly continuous delivery companion.

Otto is a robust distributed system for scalable continuous integration and delivery. To accomplish this Otto is multi-process oriented and distributed by default; all system interactions must occur over process boundaries even if executing in the same logical host. This document outlines the high level architecture but omits specific inter-process communication formats, protocols, and dependencies.

Otto does not aim to be the center of the entire continuous delivery process, but rather seeks to interoperate seamlessly with all the various components which make CD work for you.

Otto is currently not usable.

There are design documents in the rfc/ directory which can help describe the state of development for Otto.

The components are in different states of development. Please consult the README document in the subfolders for their current purpose and status.

Much of Otto is built in Rust. The project is a «cargo workspace» which means that there are multiple binaries and libraries defined in the source tree, which can all be built together via the root Cargo.toml . Much can be accomplished with cargo build and cargo test , which is easily scoped to a single project via the -p flag, for example cargo test -p otto-parser . There is also a Makefile which drives some higher-level build system behavior.

Otto is composed of many different services, which communicate via JSON over HTTP.

Running make in the root directory will list some brief help output, but some useful make targets to be aware of are documented below:

Build and strip release binaries to prepare for packaging. Most developers won’t need to execute this target.

Launch the services defined in the Procfile . This requires a cargo build ahead of time, and is really only useful for manual integration testing.

This target will build and package all the steps defined in stdlib/

Runs all the acceptance tests, typically implemented with shunit2. This target will not run cargo build or cargo test . From a fresh clone, running the acceptance tests will require an initial build, for example cargo build && make test .

Each subdirectory should have its own README with a little more information, but at a glance:

This directory contains all the command-line interfaces for Otto.

This directory contains the various pieces of shared code

RFCs (Request for Comment) are design documents for different patterns or subcomponents within Otto.

Projects in this directory are Otto’s mesh of services, which speak HTTP to provide different aspects of functionality for the Otto project.

The Otto step «Standard Library.» In essence, these are all the step libraries that are assumed to be installed by default with Otto.

Problems to Solve

Below is an incomplete listing of the problems Otto aims to solve for:

Existing tools do not model the entire continuous delivery process. Using an external tool such as Puppet, or relying on an external provider such as AWS ECS, there can be a «black hole» in the deployment. A point where control is delegated to an external system, and the orchestration tool (Otto), loses sight of what is happening.

Expecting «one single instance» to be the hub is unrealistic. Many deployment processes have «development» operated components, and «ops» operated components, with little to no automated hand-off of control between the two.

Mixing of management and execution contexts causes a myriad of issues. Many tools allow the management/orchestrator process to run user-defined workloads. This allows breaches of isolation between user-defined workloads and administrator configuration and data.

Non-deterministic runtime behavior adds instability. Without being able to «explain» a set of operations which should occur before runtime, it is impossible to determine whether or not a given delivery pipeline is correctly constructed.

Blending runtime data and logic with process definition confuses users. Related to the problem above, Providing runtime data about the process in a manner which is only accessible in the delivery process itself, overly complicates the parsing and execution of a defined continuous delivery process.

Modeling of the delivery process is blurred with build tooling. Without a clear separation of concerns between the responsibility of build tools like GNU/Make, Maven, Gradle, etc and the continuous delivery process definition, logic invariably bleeds between the two.

Opinionated platform requirements prevent easy usage across different environments. Forcing a reliance on containers, or a runtime like the Java Virtual Machine results in burdensome system configuration before starting to do the real work of defining a continuous delivery process. Without gracefully degrading in functionality depending on the system requirements which are present, users are forced to hack around the platform requirements, or spent significant worrying about and maintaining pre-requisites.

Many tools are difficult to configure by default. For most application stacks, there are common conventions which can be easily prescribed for the 80% use-case. Ruby on Rails applications will almost all look identical, and should require zero additional configuration.

Secrets and credentials can be inadvertently leaked. Many tools provide some ability to configure secrets for the continuous delivery process, but expose them to the process itself in insecure ways, which allow for leakage.

Extensibility must not come at the expense of system integrity. Systems which allow for administrator, or user-injected code at runtime cannot avoid system reliability and security problems. Extensibility is an important characteristic to support, but secondary to system integrity.

Usage cannot grow across an organization without user-defined extension. The operators of the system will not be able to provide for every eventual requirement from users. Some mechanism for extending or consolidating aspects of a continuous delivery process must exist.

Modeling Continuous Delivery

Some characteristics of a continuous delivery process model which Otto must ensure:

Deterministic ahead-of-time. Without executing the full process, it must be possible to «explain» what will happen.

External interactions must be model-able. Deferring control to an external system must be accounted for in a user-defined model. For example, submitting a deployment request, and then waiting for some external condition to be made to indicate that the deployment has completed and the service is now online. This should support both an evented model, wherein the external service «calls back» and a polling model, where the process waits until some external condition can be verified.

Branching logic, a user must be able to easily define branching logic. For example, a web application’s delivery may be different depending on whether this is a production or a staging deployment.

Describe, though not fully, environments. All applications have at least some concept of environments, whether it is a web application’s concept of staging/production, or a compiled asset’s concept of debug/release builds.

Safe credentials access, credentials should not be exposed to in a way which might allow the user-defined code to inadvertently leak the credential.

Caching data between runs must be describable in some form or fashion. Taking Maven projects as an example, where successive runs of mvn on a cold-cache will result in significant downloads of data, whereas caching

/.m2 will result in more acceptable performance.

Refactor/extensibility support in-repo or externally. Depending on whether the source repository is a monorepo, or something more modular. Common aspects of the process must be able to be templatized/parameterized in some form, and shared within the repository or via an external repository.

Scale down to near zero-configuration. the simplest model possible should simply define what platform’s conventions to use. With Rails applications, many applications are functionally in the same with their use of Bundler, Rake, and RSpec.

What is otto windows

Otto is a repository manager

Good evening, Otto. This is Agent Rogersz. I’m going to ask you a few questions. Since time is short and you may lie, I’m going to have to torture you. But I want you to know, it isn’t personal.

What does Otto do?

Otto assists in performing tasks related to a software repository. It comes with a number of common tasks which include things like:

• cloning a repository and checking out a branch
• building, testing, installing the software,
• making releases
• creating and publishing packages
• initiating and finalizing development efforts

Otto allows users to define their own tasks which may extend the applicability to suites of repositories or even processes not associated with software repositories.

How does Otto work?

At the heart of Otto is a workflow of tasks that allow transitions between states. The workflow is represented as a cyclical directed graph with states as nodes and tasks as edges. The tasks are executed and the state is held by a state machine. User interaction is needed to direct the state machine to attempt to enter a new state by executing the task that takes it there. The transition will occur if the target state is directly connected to the current state and if the task succeeds. In this manner the user need only know where they want to go and not the details of how to get there.

What are these states?

An Otto state is somewhat abstract. Specifically, it is merely a label stored in an Otto database. The states are conceptually mapped to states of “the software”. This concrete state may be a particular layout of files on disk, a particular branch checked out, a particular version installed, a particular package build and published, etc.

What are these tasks?

A task is a Python function that has been associated to the edge joining the current and target states. Often this function merely executes an external subprocess.

What about failures?

Just before task execution, Otto leaves its current state. If the task is successful it enters the target state. If the task fails, Otto enters a special error state and requires the user to explicitly reset the state machine. Before doing this the user may have to clean up the actual state of the software manually in order to allow the Otto state to be properly in sync with reality. This is why users still must have brains.

You don’t even know what’s in your own trunk! And you know what? I think you’re afraid to find out!

Otto functionality is partitioned into:

repos information and operations on individual repositories workflows defining operations and executing them constrained by a workflow