☰
Conductor Documentation

Best practices for agile blueprint development

Best practices for agile blueprint development:

Blueprint development is an iterative process that involves lots of trial and error stages. The Conductor blueprint deployment process was designed for handling updates in a production system and therefore tends to be a bit too rigid to fit into iterative development stages.

In this document we will describe the best practices for enabling more agile blueprint development and architecture that is more suitable for handling continues development needs.

We will break this down to the following parts:

Continues updates:

Continues updates The part of the blueprint that is changing most frequently during a development cycle is the lifecycle operation and workflow. Updating those resources can be done by changing the resource directly on the Conductor Manager and re-executing the workflow that execute that resource or script. Each execution will in turn execute the new version of the script on the next run on the target environment that has been previously created by the blueprint without having to re-instantiate that environment every time we want to make a change.

Deployment Update - In cases where we change the blueprint itself i.e. adding or removing node or changing the node configuration were effectively making a change to the service topology. The deployment update addresses changes to the blueprint itself (add/remove nodes) as well as to the underlying resources. It does so by re-deploying the entire blueprint and then pushing only the delta between the new version and the running version on the live deployment. The deployment update is also the recommended method for updating internal blueprint resources in a production system as it provides a more structured way to update all the resources that are part of the update including scripts and workflow operation and allow for rollback and better version control of that update.

Automating without having to write custom code

Conductor comes with a set of Generic Plugins that pre-integrates with wide range of automation domains that includes infrastructure Conductors such as AWS cloud-formation as well as configuration elements such as REST or Ansible playbooks as well as micro services such as Kubernetes services. The built-in plugins allows as to lay-out an entire automation flow without having to write custom code. The REST and Ansible plugins allows us to also handle the interaction with the service simply by plugging the right REST commands or Ansible playbooks in the relevant lifecycle operations.

Develop custom plugin There are cases where we need to handle more complex interaction with a given service that involves validation and more complex set of workflow and business logic. In such cases we can use custom-plugins to map the specific business logic of a given service into a set of node-types that can be described declaratively in the blueprint as any of the other built-in node types and thus inherit all the benefits that comes with it such as the ability to define relationship, pass inputs , tie-in workflow etc.

Custom plugin provides more control and flexibility on how we expose that service through interfaces and API that would make the modeling and interaction with that service more tight.

You can read on the best practices using built-in plugins and custom plugin in the this section of the documentation

Using micro-services approach for enabling reusable blueprint development

This section refers to some of the architecture best practices on how to develop an automation blueprint using micro-services approach.