In modern software development, speed and agility are crucial when building and releasing software. However, when large teams of developers work simultaneously, branching and merging code can quickly become messy. Teams therefore need a clear process to implement multiple changes in parallel. This is why an efficient branching strategy is a key part of the development workflow and essential for deploying with confidence.

The Appshare Development Workflow uses a branching strategy that balances simplicity with quality assurance.

A typical change moves through the following development stages:

  1. Open – Any new issue gets status New and starts 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 – The issue is refined and clearly described, ready to be taken into development.
  4. In progress – The issue is being developed and is assigned to a developer.
    1. Create a feature branch (an isolated code line).
    2. Write code.
    3. Write tests.
    4. Make a staging deployment.
    5. Update documentation.
    6. Update the app version and Release Notes.
  5. Staging Test – During this phase, the issue is still in progress, but the feature branch is deployed to the Staging environment.
    1. Test the functionality and confirm it covers all functional requirements.
    2. Consultants or customers can review the changes on the deployed URL.
  6. Review – The issue is in review when a pull request is created.
    1. When a pull request is created, the continuous integration runs quality checks and End to End (E2E) tests on the code.
    2. Another team member reviews the changes and provides recommendations for improvement.
      1. Review the source code.
      2. Review that 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 deploys the main code.
      1. A build is created with a unique build number.
      2. Deployment runs to the Appshare CDN (https://*.appshare.app).
      3. A Docker image is pushed 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, they can log in to their local node.
      1. Log in to Appshare.
      2. Open the top-right menu and select “Administration”.
      3. Select Nodes in the menu and open the Node Manager.
      4. Select the image that was previously published or a newer/higher version.
      5. In the Appshare Administration, the new build will be shown in the node.
      6. Users must log out and log back in to get the latest build on their devices.

Source code and deployment process

When development begins and a feature is in progress, a developer creates a feature branch from the main codebase. Changes are made and committed to this branch. The developer can also make local deployments that are accessible only from their workstation.

A staging deployment is created when key users need to perform functional testing. A staging deployment contains only the changes from the feature branch. When multiple features must be tested together, a dedicated branch that includes those features is created and deployed separately.

When a feature branch is merged into the main branch, it is deployed to the Appshare public SaaS, and a local node image is created. Customers can pull this local node image so users can access the new features.

image.png

Local Node for Infrastructure testing

To get the most value from a local node while still testing efficiently on the Appshare platform, the workflow can be split into two steps. The first focuses on functional requirements; the second focuses on infrastructure (non-functional) requirements.

The first (functional) step follows the development stages above. The second (infrastructure) step is implemented as a DTAP (Development, Test, Acceptance, Production) setup with local node instances. Each local node instance runs on a separate port and has settings for the target infrastructure.

An image delivered by the first step can then be deployed to each local node instance in each DTAP environment and tested in the target infrastructure.