Development process

By Dmitry Melnikov on August 16, 2018

Introduction

When working with a new system, developers need to take into account peculiarities of the system in order to adjust the development process accordingly. In this article, I will describe how to organize your development process with DWKit. It is worth mentioning, that whatever methodology you are using (Agile, Scrum, Waterfall, etc.), DWKit will easily fit it.

Development process

A standard development process might be described as follows:

  1. Responsible team members assign a set of tasks
  2. The tasks are allocated between the developers
  3. The changes made by developers are merged
  4. System release is formed
  5. The release is deployed to the testing environment and is tested
  6. In case there are bugs, the release is returned back to development
  7. If testing is successful, the product system is updated
Task assignmentMerge of changesReleaseTestProductionBranch 2Branch 1Branch 3Branch 4Development

The most difficult processes here are:

  • Coordination of developers’ teamwork and merge of changes
  • Changes transfer process

Besides, it is necessary to follow library and component updates. The recommendations for each of the changes will be provided in the next sections.

Teamwork coordination

We distinguish 5 types of changes that could occur during the development process with DWKit. For each type of changes a change merge method is specified. We advise you to use modern source control tools, such as Git or Mercurial. They have in-built features for merging all file formats used in DWKit.

Type of changes Change merge method
C# code Merge is executed with standard source control tools
JS/JSX/CSS codes Merge is executed with standard source control tools. When changing JSX, you need to repack the React app using webpack or other tools. More details are available here.
DWKit metadata The metadata are kept in JSON in the Metadata folder. Merge is executed with standard source control tools. Most source control tools work well with JSON.
Workflow schemes Should be kept in the form of XML scheme descriptions or in the form of an SQL script, which updates the WorkflowScheme table. Merge with standard source control tools is possible.
Database structure Prepare scripts or use third-party tools.

Change migration process

Change migration from the development to the testing environment and further to the production environment is done with the standard Visual Studio tools. Ensure that you’ve set the following properties for all files stored in the Metadata folder

  • Build Action = Content
  • Copy to OutputDirectory = Copy always.

Otherwise, Visual Studio might not copy these files upon publishing.

AppSettings, Security, and Workflow are stored in the database. If you haven’t created scripts for them, you need to execute these scripts in the database. Otherwise you may make the necessary changes manually using the DWKit admin panel. If you store Workflow Schemes as XML files, you should secure their upload to the WorkflowSchemes table. It could be done via the admin panel. Currently, DWKit doesn’t support batch update of the app via the admin panel. This task is on our RoadMap.

DWKit updates

We publish all new versions of DWKit on our website in the Downloads section and in NuGet. The users that specify their email address when downloading the product from the official website are notified about all new versions.

If you purchased the license with the source code, you need to request the source code of the most recent version at support@optimajet.com. When updating the database structure, we add a script in the following format to the provider’s package:

  • update_<old version>to<new version>.sql

You will need to launch this script in your database. If you use the StarterPack or develop a system on the basis of one of the examples provided, you should check for the changes in the OptimaJet.DWKit.Application and OptimaJet.DWKit.StarterApplication projects.

Conclusion

DWKit doesn’t require any changes in the development process used by your team regardless of the applied methodology. It’s a perfect tool for teams that use feature branches. Still, you might need to adjust continuous integration settings used in your work.