To remain the #1 .NET workflow product, FlowWright consistently delivers significant functionality, feature, and performance upgrades. Please review the published version history for details and read the "read me" file associated with each version for more details about each product release.
FlowWright product managers determine what to build next with our top priority items driven by feedback we get from our customers. We ask: what problems can FlowWright solve for them, what will achieve operational and process excellence, what will lead to successful and continuous digital transformation?
Once priorities are agreed upon for a new version, the collaborative effort with product development, QA, documentation, support, sales, marketing, and delivery teams begins!
So how do we consistently deliver the best .NET workflow and business process automation software for industry? Well, it is simple: we are fully automated! We use FlowWright to automate our own agile product development processes and other processes. When it came to delivery of FlowWright v9.6.1, here’s one actual workflow that was executed. Below is the main workflow process, which in turn are divided into sub-processes.
As you can see from the main workflow, one of the first things we perform through a sub-workflow is source code control. Source code sub-workflow involves the following:
This sub-process involves branching the source code for the next version of the product (a standard function of any source code provider.) Next, the DLL version is changed to match the next product version, since our product development can span years, sometimes we also have to change the copyright year, especially for minor versions.
Going back to the main workflow, once the source code control task is completed, it branches off to many sub-workflows, but one of them is the “Requirements” sub-workflow.
The above sub-workflow verifies new requirements, bug fixes and the product release plan is created and reviewed for the new version. The “Release project plan” task could be open throughout the whole process!
Next are the sub-workflows, and these are separated into the following groups:
- Test cases and documents
- Product documentation
- Beta release
The “Development” sub-workflow breaks into many tasks assigned to the development team. These involve implementing new enhancements, fixing bugs, unit testing, code documentation, updating automated testing and the REST APIs.
As development progresses on a new version, other activities/sub-workflows execute in parallel. One of these parallel sub-workflows includes tasks assigned to the testing team, and it looks like:
The testing team needs to: prepare a test plan, create new test cases for new functionality and, when new functions are ready for QA, execute test cases. Once test cases are executed that test functionality, the new FlowWright version will be run through different kinds of testing that are described in the next sub-workflow.
Subsequent to functionality testing, the team does system testing as well as additional testing in parallel. QA puts FlowWright through rigorous regression testing to test out performance and load tolerance. To ensure success for global customers, we perform variations of culture testing, for example for en-GB (British English) and de-DE (German), and then test use of designer and date/time formats throughout the application against property culture-based formats, including database level testing using database accounts for foreign cultures and languages.
We support all modern browsers, so QA tests FlowWright against Google Chrome, Firefox, Microsoft Edge, and Safari on Macintosh. Because FlowWright forms and UI are responsive, the UI is also tested on various devices for issues, performance, and usability.
Most FlowWright UIs communicate using the FlowWright API, and the API gets tested from functional and unit levels. The REST API is also tested to ensure it accounts for all enhancements and changes.
When FlowWright is fully tested, a package is created using InstallShield, and this package is then thoroughly tested. FlowWright provides 2 installers, 1) one that installs the complete package including Microsoft SQL Server and the database, and 2) an upgrade package for existing customers to install.
Upgrade testing is performed using the upgrade package - always against the last two previous major versions. Upgrade testing requires much validation!
Documentation is another parallel activity executed by the documentation team. FlowWright provides many levels of documentation.
FlowWright provides documentation for workflow steps and form UI widgets, the user manual, installation, upgrade and release documentation. Most documentation involves significant collaboration between teams to ensure customers and developers understand functionality (especially how to extend FlowWright.) Documentation tasks are assigned, completed, and then reviewed by other members of the FlowWright team (as shown above!)
Within 1 month of release of a new version release, a beta version is sent to some beta customers. This process is managed using the following sub-workflow:
We receive helpful feedback during beta testing that inform important changes and help make FlowWright ready for pre-release.
The next stage is "pre-release", where many checks and balances are acted through by team members.
In some cases, we might increase the DLL version before release. Because development can occur over year end, copyright information for each DLL needs to be updated also. The final software installer is then built and packaged for delivery. This includes creating a NuGet package for the .Net API. Final documentation reviews are performed and the release installation package is tested.
On Release Day, we are all excited! But, according to our workflow, we still have tasks to complete. Here’s the final sub-workflow that releases our software:
At this point, we verify all VSTS development issues are closed, source code is checked in, and that code is labeled for release and promoted. The final package that was built during the pre-release phase is placed in dropbox, and the version history and download links on our website is updated with new information.
Then, we notify the world about the new version! Marketing sends notifications to existing customers about the new version, and then makes a broader announcement on various social networks such as Facebook, LinkedIn, Twitter and other sites.
Typically software gets released in the morning around 11 am Eastern time in the USA. Once the software is released, it's time to enjoy, and the product team goes to enjoy some time out of the office!
At this point, our new release workflow ends. Even though this workflow ends, other processes keep moving: marketing, social, feedback, etc.
Building commercial software is not easy, it’s even harder to maintain a product with a large number of customers all over the globe, but automation is the key to making it manageable and fun.
All this automation is done using our FlowWrightPM project management product, which in turn runs on top of FlowWright using many of the FlowWright core features. Here’s a preview of what the UI for FlowWrightPM.
Many customers use FlowWrightPM to manage their capital and critical IT projects, such as ERP cutovers and upgrades and more. Contact us today, if you like to get a demo of this product.