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 components and processes involved with cloud development. A description of the follows the image.
The above image shows the different components involved with developing and deploying code in a hosted cloud environment. The workflow for this is as follows:
Development Workflow
Each member of the development team starts by installing Workflow Studio on their workstation with their own container and URL (personal cloud) for development. When Workflow Studio is installed, 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 on the local machine, while the WFS folder contains sub-folders containing EmpowerID stock assemblies and product packages. The content in these folders are tied to a Git repository that is unique for the development team’s organization and should not be modified. Any modifications to the stock EmpowerID packages occurs in specially designated folders named _assemblies and <Customizations> (This folder can be renamed to match the organization name.) 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.
what the folder structure. these stock assemblies needs to occur in a specially designated folder namedtakes place in specially designated folders that developers create on their workstation. The pertinent folders should be named _assemblies and CustomizationsThe folder structure created by the installer looks like the following image.
. additional sub-folders named _stock_assemblies, , the stock assemblies and EmpowerID product packages. The installer When installed, several folders are written to the file system. TheseGenerally, each personal cloud is connected to a common database and Git repo. Development occurs on a workstationcan be connected to a common database and Git repos.
Each developer has a workstation with Workflow Studio installed against which they develop. Any development work occurs on the workstation and is saved in the appropriate EmpowerID folders. The structure for the folders is as follows:
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 customized Web elements, such as .CSHTML pages and CSS files, are saved.
WFS/<Customizations> — This folder stores any custom Workflow Studio design items developed, 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 as needed. For example, if you belong to organization “Foo,” the folder can be renamed to “Foo.”
WFS/_assemblies — This folder contains all compiled Workflow Studio item.
Each developer has a personal cloud tied to their workstation, which is represented by the Developer Containers depicted in the above image. Development work that is compiled and published on a developer’s workstation is placed in the WFS/_assemblies folder on that developer’s workstation as well as deposited to the developer’s personal container.
When a developer’s work is ready to be shared with the team, that developer commits their work to the Git repository.
When new development is committed to Git, the build process automatically starts. This process copies the contents of the customized folders mentioned above and overlays them on top of the corresponding folder in an EmpowerID stock image. This creates a new image that is based on the EmpowerID stock image plus the the customized development work.
So, the idea is that the development is going to happen on workstations and the running of EmpowerID is going to be in the cloud. So, that is what we are gearing this topic toward. Is somewhat applicable to on-prem installations. Still have a heavy bit of dev on servers. Migrating things.
Regardless, here are the folders you would be working with. Highlight the few folders we are going to capture into source control.
Dev install EmpowerID—not have app pools or windows services. Would have programs subfolder and website folder and WFS folder. Run WFS from the programs folder. Like on-prem. The difference is when asked for URL, you enter your cloud URL. Each developer will have their own URL. So, imagine if we belong to common lab called lab1 then have Phillip.lab1.empowerid.net, Nirav have Nirav.lab1.empowerid.net. Each developer has their own container that they are working with and affecting while doing development. Collectively all developers working in an environment might be tied to a common development environment. Represented by lab1 in the example. Folders on our workstation that are bound to a common git repo. So what you would be doing as a developer is running WFS locally, publishing workflows, creating connectors, doing other such customizations and as you
See the image. Share common git repo and container registry. Build pipeline that takes customization and applies them to EmpowerID stock images. As a dev run WFS locally publishing workflows, creating connectors and doing other such customizations. As you publish this stuff files are going to start accumulating in WFS folder. Design changes, such as things you author or EmpowerID product packages that you modify, those design items accumulate in the WFS – customizations folder. So, if we are in a common lab environment called lab1 and an organization named foo, then the customizations folder would be named foo. Design items go there. As a best practice any modifications or new workflows do not modify directly in EmpowerID Product Packages folder. Any workflows we create or modify, they are copied and moved into the foo folder. When compile and publish, the DLL is put into the _assemblies folder. EmpowerID stock DLLs and design items are placed in the _stock_assemblies folder and the EmpowerID Product Packages folder, respectively.
From Diagram: So I do my work. Any workflow or other WFS items that I compile and publish into an assembly when I publish I put it directly put onto my container, container A (developer A). I am also depositing that file on my local workstation in the _assemblies folder. If I publish something that doesn’t necessarily mean that User B will get that change just by me having published. Even if dev B restarts their container. Blue arrow represents dev A in their normal mode of operations as they are developing, testing , publishing, modifying, testing publishing. When I have something mature enough that I want to share out then I push my changes to the GIT repo (committed it to GIT). We work out what branch we are bound to. (This topic is not on best practices for developing in EmpowerID using GIT.) By me committing it to GIT, the build process automatically kicks off. The build process takes those folders identified above and overlays them on top of our stock images in the corresponding folder. So imagine the build process where you build on top of other things, you take EmpowerID’s stock image and you overlay your customizations onto that creating a new image that is based on the EmpowerID stock image plus your customizations. That build process takes the EmpowerID stock image, overlays the customizations from GIT and then creates a new image that goes to the container registry. That image is put into the container registry and the image gets deployued to the environment either automcatically or ad-hoc by request from dev a or dev b. At some point the devs would be running the new image with the customizations added to GIT. The red path (path) indicates how to commit my changes for good. As dev a anything that you publish to Container A, if you don’t put it into GIT, then you will lose it the next time Container A restarts or starts up. So, recommended that once your work has some level of maturity that you commit to GIT. By losing changes, all I mean that all you publish out there is not going to be there. Don’t push broken code but in order to keep from encountering a bunch of errors, commit to GIT and allow pipeline to build. Both devs should be up to date with the latest image. Thinking about deploying builds out or let devs run a workflow to build new image. Work is on workstation so when you start your container, you can publish again but the problem is sometimes you are not going to know or wonder. (Still working out giving info to user in the UI for clarity. Red path, when you commit to GIT it runs a process that can take up to 10 minutes for the process to complete (solidifies changes). Blue path is temporary working way to get your changes out there to your container testing, etc. RB uses this today. They use the red path commit to git, new image.
If you look at this from a classical scenario -dev-uat-prod see second image. Every time you build a new image (commit to GIT) you are capturing that point in time and the image is given a tag (like a, b or c as in the image). Doing dev in c or dev and could be rotating through images very quickly. At some point decide that dev is complete enough to promote to testing. Pick the tag and promote it. Prod runs something that you validate. Release management using tags. This is it from a high level guidance. Haven’t talked about branching strategy or how things get promoted from UAT to Prod. Or db customizations. Get this topic started how to proceed.