...
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.
...
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 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.
...