A typical change goes through the following development stages

1. Open – Any new issue gets status New and ends up in this stage
2. Refinement – The issue is ready to be technically refined.
   1. The issue should have a clear description
   2. Acceptance criteria – requirements
   3. Non-functional criteria
   4. Test cases
3. Development Ready – Issue is refined and clearly described to be taken into development
4. In progress – Issue is taken in development and is assigned to a developer
   1. Create feature branch, an isolated codeline
   2. Write code
   3. Write tests
   4. Make a staging deployment
   5. Update documentation
   6. Update app version and Release Notes
5. Staging Test – During this phase the issue is still in progress, but the feature branch is deployed to Staging Environment
   1. Test the functionality and check that it covers all functional requirements.
   2. Consultants or customers can review the changes on the deployed url.
6. Review – The issue is in state review when a pull request is made.
   1. When a pull request is created, the continuous integration runs quality check and End to End (E2E) tests on the code.
   2. Another team member reviews the changes and gives recommendations for improvements.
      1. Review the source code
      2. Review Translations are present
      3. Review Release Notes
      4. Any other recommendations
7. Done – After the pull request is merged the issue ends in this stage
   1. After the merge the continuous deployment runs to deploy the main code.
      1. A build is created with a unique build number
      2. Deployment runs to the Appshare CDN (https://*.appshare.app)
      3. Push of docker image to DockerHub to be used later in a Local Node
8. After care:
   1. Notify the customer that the change is available
   2. If the customer uses a local node then they can login to their local node
      1. Login to Appshare
      2. Open the top right menu and select “Administration”
      3. Select Nodes in the menu and open the Node Manager
      4. The customer can select the images which was previously published or a newer/higher version
      5. Inside the Appshare Administration the new build will be shown inside the node
      6. Users must logout and login again to get the latest build on their devices

Source code and deployment process

When development starts and a feature is in progress then a developer creates a feature branch of the main source code. Changes in the source code are made and added to the feature branch. A developer makes local deployments which are only accessible from the local workstation.

A staging deployment is made when functional tests must be preformed by key users. A staging deployment contains only the changes from the feature branch. When multiple features must be tested together then the a branch with these features must be created an deployed separately.

When a feature branch is merged into the main sources then it is pushed to the Appshare public SaaS and a local node image is created. Customers can pull this new local node image to use the new features by their users.

To benefit the most from a local node and at the same time being efficient with testing new applications on the Appshare platform the workflow can be split into two steps. The first one is focused on the functional requirements and the second on the infrastructure (non-functional) requirements. The first functional step follows the development stages . The second infrastructure step is implemented as a DTAP (Development, Test, Acceptance, Production) with local node instances. Each local node instance has a separate port and settings for each target infrastructure. An image which is delivered by the first step can be deployed to each local node instance of each DTAP envrionment separately and tested inside the target infrastructure.