About the EmpowerID Cloud Developer Service

Owned by Phillip Hanegan
Last updated: Nov 15, 2020
5 min read

EmpowerID Cloud is a cloud-based version of EmpowerID that provides organizations access to the EmpowerID IAM and Workflow Development Platform as a Services (PaaS) within a hosted environment. As a Workflow Studio developer, this provides you with the advantages inherent to cloud development. These advantages include the following:

  • Lightweight installation of Workflow Studio. Each developer installs Workflow Studio on their workstation. This installation creates a working directory for EmpowerID containing required EmpowerID assemblies, stock Workflow Studio assemblies and EmpowerID product packages. EmpowerID app pools and Windows services are excluded from the installation.

  • Git repositories for source code

  • SQL Azure Database

  • Each developer has their own container and URL (personal cloud), which can be connected to a common database and Git repository and shared to the personal clouds of each developer. Collectively, these personal clouds are known as a development environment.

  • Automated build pipeline with continuous integration for quicker deployment of changes to development, testing and production environments

     

The below image shows a high-level overview of the workflow in EmpowerID Cloud.

 

The image shows how a team of developers work together to develop, test and deploy EmpowerID solutions in EmpowerID Cloud.

Development environment

Each member of the development team starts by installing Workflow Studio on their workstation with their own container and URL (personal cloud) for development. The installer creates a root TheDotNetFactory folder with two subfolders named EmpowerID and WFS. The EmpowerID folder contains required assemblies and executables for running Workflow Studio, while the WFS folder contains stock EmpowerID assemblies and product packages. These folders are tied to a Git repository that is unique for the development team’s organization. The content of these folders should not be modified. New development work occurs in the folders designated for such.

The below image shows how the folders are structured in the organization’s Git repository. The folders with black text are the folders that can be updated with custom content.

  • EmpowerID — This is the root installation folder. (Note that this folder should not be the root of the source control).

  • EmpowerID.Web.Overrides and EmpowerID.Web.CDN/Overrides — These folders are where Web customizations, such as .CSHTML pages and CSS files, are saved.

  • WFS/_assemblies — This folder contains compiled custom Workflow Studio items.

  • WFS/<Customizations> — This folder stores any custom Workflow Studio design items, such as new workflows, forms, connectors, etc., as well as any modifications made to stock EmpowerID Product items. Note that stock EmpowerID product items should first be copied to this folder and then modified. The folder can be renamed to reflect the organization. For example, if you belong to organization “Foo,” the folder can be renamed to “Foo.”

Development Process

As each developer goes about their tasks, running Workflow Studio locally, publishing workflows, creating connectors, and modifying existing items, their work accumulates in the WFS folder on their workstation. Design changes, such as any new Workflow Studio items they author or EmpowerID product packages they modify, are saved in the Customizations folder, which is generally named after their organization. When a developer is ready to test their work, they compile and publish it. When an item is published, an assembly for it is added to the _assemblies folder on the developer’s machine and the developer’s personal cloud.

The below image shows what occurs when two developers, Steve and Heidi, work on separate features.

Notice that Steve’s and Heidi’s development clouds remain separate, but share a common dev environment. This allows them to review and validate each other’s work if needed. Once a developer has their feature at a mature enough stage, they can push their work to a designated branch on the Git repository. This automatically kicks off the build process.

The below image shows the difference between publishing and pushing work to Git. Publishing adds the work to the developer’s cloud, while committing the work to Git kicks off the build process.

 

Work that you publish to your container will be removed from the container each time you start it. The work will still be in your folder on your workstation, so it is not lost. This just means that you will need to republish it to add it back to your container. As this is the case, EmpowerID recommends that you commit your work to Git often.

The build process takes the EmpowerID stock image, overlays it with the custom work on a developer’s workstation and creates a new image from it. The new image is added to the container registry. Once the image is added the container registry, it can then be deployed to the dev environment automatically or ad-hoc as needed. This process takes about 10 minutes to complete. Once the build has completed, other members of the development team can then pull that image.

 

Moving builds

Every time a developer builds a new image (commits to Git), that developer is capturing code from that point in time and the resulting image is given a tag. While in the development environment, image rotation can occur very quickly. At some point, the team is going to decide that development is complete enough to promote to testing. When this is the case, they pick the relevant tag and promote it to UAT, where it is tested. Once testing is complete and the build is validated, it can be released to production.