Appshare Administrators Guide

  2. Home
  4. Docs
  6. Appshare Administrators G...
  8. Appshare Change Management

Appshare Change Management

In modern software development, speed and agility are crucial when it comes to developing and releasing software. However, when you have a large team of developers working simultaneously, branching and merging code can become messy fast. Therefore, teams need to have a process in place to implement multiple changes at once. This is where having an efficient branching strategy becomes a priority in Development workflow and to be able to deploy with confidence. The Appshare Development Workflow implements a branching strategy which is a balance between simplicity and quality assurance.
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

Local Node for Infrastructure testing

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 stages described for the appshare development workflow. The second infrastructure step is implemented as a DTAP (Development, Test, Acceptance, Production) with local node instances. An image which is delivered by the first step can be deployed to each local node instance separately and tested inside the target infrastructure.

Appshare Testing Best Practices

Use your Appshare Local Node against your JDEdwards production environment to support production transactions. Obviously you can also access all other JDEDwards environments from that same node should that be required.

When new applications are made available to you, or new features have been added to existing ones, the developers will include a beta testing link in your application to access the new features for testing purposes. This testing will most likely be done in non prod environnments and occur on a pre-production Appshare node, indicated in the picture above as staging node at the bottom of the picture.

When tested successfully, the new application or application feature will be deployed in the Appshare cloud. The beta testing link in the application will disappear, as the new application of feature is now available in the common Appshare platform.

The local administrator can now apply the new Appshare image to the local node, to make the feature available in the Appshare local node.

How can we help?