Using EASYProcess Overview
After opening EASYProcess once the correct Application is selected, you will arrive at the Application Home screen.
The Application Home provides a few useful tools to navigate to various important Areas of EASYProcess. On the left-hand side, you have some buttons to take you to some most-used areas of EASYProcess such as Processes, WebParts, Web Pages, and Configurations. On the right-hand side, you have a screen with your most used items and some data about when you last accessed them.
WebParts have to do with front-end, UI changes. Processes have to do with back-end logic or algorithmic changes. For instance, if you wanted a page with a drop down list and a button to save the user’s selection, the drop down list and the button would be created through a webpart. However, the logic to decide what values populate the drop down and how and what to save from the user’s selection would be done in a process.
WebParts and Processes are examples of how EASYProcess uses modular pieces to create applications. Each piece EASYProcess uses to build the Application are considered EASYProcess Entities.
This means the website you create will consist of many different pieces or Entities. For example, a single page on an application will have a Web Page, a WebPart that actually contains what will show on the page, and a Process to run the logic behind the scenes. All of these are Entities meaning they represent a record in the Application’s Database and then EASYProcess keeps its own copy of them so that it can perform the equivalent of SQL table joins, except it can manipulate the data in a quick way that is easier with Entities.
Developing in EASYProcess consists of having an Application set up with three (or more) environments. Source Control Management (SCM) should be set up to keep the Development (DV) environment for making changes, the Quality Assurance Testing (QA) environment for testing those changes from a user perspective, and Production (PD) as the live and most stable version of the application that remains customer-facing. These three environments for the Promotion Path which a developer will move sources through during the life of the Feature/Change.
When a developer wishes to add a feature or change an existing one, it should follow the Feature Design Best Practices. These include steps to follow for designing a feature to ensure the success of the development.
When developing, the developer will check entities out in SCM and make changes in the DV environment. This may involve changes to entities like Web Pages, WebParts and Processes. It may also require changes to more complex EASYProcess tools like Configuration Variables, Batch Jobs, CSS, APIs, or Workflows. The developer should follow the Development Best Practices.
During development, the developer should utilize the EASYProcess Logs to confirm Processes are running as expected and there are no bugs. When a bug is encountered the developer should follow the Troubleshooting Best Practices to help identify the cause of the issue.
The Developer and Tester will work together to perform all necessary testing in the DV and QA environment. Testing should follow the Testing Best Practices to ensure the success of the testing step.
When ready and fully tested, a time should be decided to promote to the PD environment. Some promotions include site downtime and should be accounted for by promoting after certain business hours or during a scheduled downtime window. All promoting of sources should follow the Promotion Best Practices to ensure the success of the promotion step.