Page Comparison

...

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:

...

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. When Workflow Studio is installed, the 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 stock EmpowerID stock assemblies and product packages. The content in these These folders are tied to a Git repository that is unique for the development team’s organization and . The content of these folders should not be modified. Any modifications to the stock EmpowerID packages New development work occurs in specially designated folders named _assemblies and <Customizations> (This folder can be renamed to match the organization name.) 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.

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

  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

  developed

  , 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

  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.

...

Development Process

As each developer goes about their tasks, running Workflow Studio locally, publishing workflows, creating connectors, doing other such customizations and as youSee 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 folderand modifying existing items, their work accumulates in the WFS folder on their workstation. Design changes, such as things you any new Workflow Studio items they author or EmpowerID product packages that you they modify, those design items accumulate are saved in the WFS – customizations 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 , 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.

...

The build process takes the EmpowerID stock image, overlays the customizations from GIT and then creates a new image that goes 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. That Once the image is put into added the container registry and the image gets deployued , it can then be deployed to the dev environment either automcatically automatically 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 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. Pick the When this is the case, they pick the relevant tag and promote it to UAT, where 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.is tested. Once testing is complete and the build is validated, it can be released to production.