- Introduction to WorkXpress
- Building Your Application
- Examples and Best Practices
- Technical Manual
An application is created by installing a DNA file into an infrastructure environment and assigning it a role. There are three roles: development, testing and production. Testing and production applications are always associated with a root development application.
Version control is managed by maintaining a history of versions of a development application. Each version is an application DNA file. You may release new versions of development applications and update to newer versions of testing and production applications at any time.
You may merge a DNA file into a development application to create an application that consists of both sets of functionality.
The WorkXpress Cloud Management Portal is used to manage your applications, maintain version histories, perform releases and updates, and to merge application functionality.
An application is any software program that you are developing, testing, or using in production. Technically speaking, an application is actually “any piece of WorkXpress DNA deployed into some infrastructure environment and installed into either a development, testing, or production role,” but we'll cover this more soon.
All WorkXpress applications are described entirely by data in a database. That data contains the “genetic” information necessary to build a WorkXpress application.
That data can be extracted into an XML file which may or may not be encrypted. In WorkXpress, that file is commonly referred to as a “DNA File” or “Application DNA”.
The process of creating a WorkXpress application involves installing or “injecting” an Application DNA File into an empty WorkXpress environment. The result is a fully functional application as described by the DNA File.
You may merge mulitple DNA files together to create a new application from the combination of the source applications.
Other times, you may extract a portion of the Application DNA from a particular application to create a new DNA file or application from a subset of the source application.
An application can have one of three roles: Development, Testing, or Production.
Roles help determine whether the build tools are to be enabled, whether the application is billable, and so on. Roles may never be changed, although it is simple to setup a copy of the application in a different role. For example, you may have more than one version of the testing application built from the same development application.
Each role has a number of options available to perform various actions, such as seeing a version history or performing a backup. Some options are available in all the roles with small differences in what they do.
Options Common to All Roles | Development | Testing | Production |
---|---|---|---|
Launch Application | This will open the application role. You can also launch an application by clicking on the orange bar that says “Click to Launch” on each role. | ||
Application Overview | The Application Overview page allows you to see information about your application, such as the hosting provider and who to call if you have questions. | ||
Activity Log | Information from initial install of your application Updates to your version of the 5GL Engine Releases of a version of your application Merging of components from other applications | Information regarding initial application install Updates of the installed application version Back ups of data and restored backups |
|
Copy Application | You can copy a Development application to make customization or to experiment with changes before sending to the testing version. | Copying a Testing application allows you to create a new data set. | Copying a Production allows you to start a customer with preloaded data. |
Move Application | You can move your application to a new cloud server. | ||
Detach From Cloud | You would detach an application if: - the application is on your own server and you'd like to save space - if you are not hosting your own application and wish to save hosting costs - if your application is in production, you may wish to save software costs |
||
Destroy this Application | This is irreversible. All of your application and its data will be permanently destroyed. |
Options Available in Development Role Only | |
---|---|
Version History | The version history shows the date and time of all releases of the development application, as well as any notes about the release. The DNA file is also available for download. |
Modules | You can see what modules have been added to your application and add new ones, such as multi-tenant billing. Some modules have a cost associated with their installation. |
Options Available in Testing Role Only | |
---|---|
See and Schedule Backups | You can schedule automatic backups and perform one-time backups on this screen. You can also choose to restore from a backup. |
See URLs | You can add a custom URL to your application. You can use the Workxpress domain or your own. |
Option Available in Production Role Only | |
---|---|
See Usage | This is an overview of how many users have been accessing your application. |
A development application must always exist and be identified for any testing or production application. This enables a clear development lifecyle for each application. When a new release is approved from the development application, an update becomes available for any linked testing or production applications. However, a development application may exist by itself.
Sometimes, a production application is installed directly from the WorkXpress store. When that happens, the production application will point to the originating development application which is managed by that application's creator. Many production or testing applications might point to this single project.
You may fork an application at any time by creating a new development application for most testing or production applications. Most commonly, this is done by taking a purchased production application and adding customizaton to it using the WorkXpress Store, in which the case the forking occurs automatically.
Later, if customization is added to the production application described above via the WorkXpress Store, a completely new development application will be created and paired with it. By adding customization to the production application, you have created a fork from the original development application, and this forked development application will now be maintained by you separately from the original one.
A fork in development occurs any time a copy of a development application is made with the goal of moving that new development application down an independent path.
WorkXpress supports a system of version management and version control. As a result, every WorkXpress application has both an application name and a version number:
You may view the entire version history of any given application. Each version is a distinct DNA file and may be independently installed into an empty WorkXpress environment as an application.
Access the version history of any application in the development role through the WorkXpress Cloud Management Portal. Simply use the “View Version History” software option.
In order to deploy a development project to testing or production, you will need to be familiar with the related concepts of rollouts, releases, and updates. Below, you'll find an illustration depicting version management, and in the following few sections, we'll familiarize you with the steps you must take to deploy your software.
Rolling out changes from a development application to a testing or production application involves two steps:
Both these steps are required to move a current version of an application from development to production.
A release is always performed from a development application. A release saves a copy of the development application in its current state, creating an Application DNA file. This release takes the name of the development application coupled with the version number of the application at the time it was released. If the appropriate option is chosen, all testing and production applications connected to this development application will be notified that a new release is now available.
The development application itself then has its version number permanently incremented by one. You may the continue to make changes to the development application.
An update is always performed on a testing or production application. It involves indicating the desire to perform an update, selecting the version to which you'd like to update, and then running the update. All of these activities may be performed easily using the WorkXpress Cloud Management Portal.
Your application will be unavailable to users during a rollout, release, or update.
You may use the WorXpress Cloud Management Portal to merge a DNA file into an existing development application, effectively combining two applications.