Features supported - User Guide to WSO2 App Factory

WSO2 App Factory -

• Solution for an organization to offer a managed environment for 3rd parties to innovate around the capabilities of it
• Enforces the best practices,
• Identify problems at early stage,
• Reduce the time to provision tools
• Shared, multi-tenant, elastic, self service, PaaS for multiple project teams to collaboratively create, develop, deploy the enterprise applications and Shares infrastructure to its developers with all useful to develop applications
• One stop shop to view the applications in an organization or a company.

Following is the URL for the Preview version of WSO2 App Factory :

https://appfactorypreview.wso2.com/appmgt/

This post will provide the features supported in WSO2 App Factory (alpha/preview).

Login

• A successfully registered user will be able to login to the system by providing the username and the password.
  
  

  

   Login Page View

App Factory Home Page

• Once the user is logged in, list of applications will be visible on the App Factory home page.
• Logged in user can play the role of an application owner by creating a new application by using Add New Application feature.
• This section includes all the applications which the current user is dealt with as an Application owner or a Developer or a QA/Tester or a Developer Ops/Dev-Ops.
  
  

  

  AppFactory Home Page View

Application Creation

• Current system suppors, WAR, JAX-RS, JAX-WS applications.
• Application key is the unique identity to a relevant application.
• The user who creates the application will become the app owner.
  
  

  

   Application Creation Page View

User Administration

• Once an Application owner clicks on the application in the App Factory home page, he or she will be bale to view the User Administration tab for the particular application.
• Application owner can specify the email address and the role to invite users to the application.
• Application owner can be a Developer, QA or even a Dev-Ops.
• Even the same user can play 2 or more roles if the relevant user is invited to the particular role.
• After a successful invitation, the invited user should be able to view the application in the App Factory home page once he or she is logged in.
  
  

  

   User Administration Page View

Application Home Page/Application Dashboard

• Depends on the role the visibility of the features for a relevant application will be vary.
• Application owner will be exposed to the all the tabs whereas a Developer, Tester and a Dev-Ops will not see some other tabs.
• E.g., A QA/Tester will see only the Governance, Track Issues and Configure Resources tabs.
• Application dashboard will list down the branches/versions of a particular application, its last build status, life cycle stage of the relevant version and the launch option for the current environment along with the check out and browse repository URLs.
• Checkout URL can be used to checkout the code in to the local machine and perform implementation of the application and then commit it. Steps to perform this task using GIT is explained in the following blog post.
  http://ushanib.blogspot.com/2013/02/steps-to-checkout-and-commit-wso2.html
• Once the user clicks on the Browse URL, he or she will be navigated to the GIT Blit. By providing user credentials, depends on the user roles, repository history will be visible to the user in GIT Blit.
• All the users will be listed down with the label of the user role.
• Summary of the Issues reported will also be available with the status of them.
• Datasources, APIs, Properties and databases created will be available as well in the application dashboard.
• App owner will be able to view the relevant Database information of the each users, whereas the other users will be exposed to their environment information under Database Section. 
  
  

  

  Application Home Page/Dashboard View

Repository

• Repository is the place where the user who has developer rights/developer or the application owner is granted to branch out a particular version from the trunk or another version of the project.
• User can provide the version E.g., 1.0.0 and branch out.
• After a successful notification, user will be able to see the newly created branch.
• All the existing branches for a particular application will be sorted and listed in the repository tab.
  
  

  

   

                 Repository Page View

 

 

Notifications

• Notifications panel is where you see the activities you have done for a particular application.
  E.g., creating the application, build status of the branches.
• This panel will be available among all the tabs.

Builds

• Builds tab is where you will be able to view the build status of a particular project for its versions.
• The existing versions which are still in the Development stage and the build status will be sorted and listed down in this page.
• If any of the version is in the testing, staging or production, it will not be visible in the Builds page. E.g., If 1.0.0 is in testing, Builds page will not have that branch.
• Build graph illustrates the build status of a particular version.
• Only the App owner and the developer will be exposed to this tab.
• Once a new branch is created, it will be auto built and deployed within 10 minutes.
• Auto built and auto deploy options are selected by default and a user will be able to untick them and manually build and deploy just by clicking on the Start Build and Deploy buttons.
• If the auto build and auto deploy options are selected, once a developer commits the changes, it will be auto built and deployed in a periodic manner.
• Jenkins build server will check the commits in every 10 minutes time and build the latest source code and deploy it.
• Once the user refresh the Builds page, user will be able to view the Build <number>' s status and a link to launch the deployed application in the relevant environment.
  E.g., When the1.0.0 is built and deployed in Development environment, launch link direct the user to the development server environment.
  
  

  

  Build View

Governance

• This is where the governance of a project comes to play.
• This option is available for all the users in a particular application.
• Mainly there are 2 options, which are Promote and Demote. Promote will take it up to the next stage and demote will take it back to the previous stage.
• If a developer is satisfied with the created application up to their expected release stage, they can promote it to the testing stage for QAs/Testers to perform their testing in the testing environment. Same as a tester can promote it to the next stage, which is staging environment if the application is up to the standard they expect or demote it back to the Development stage and reporting the issues using Track Issues feature.
• Number of mandatory checklist items will be available for every stage to ensure the quality of the tasks carried out during the promotion of a particular application version.
• E.g., Code Completed*, Design Review Done*, Code Review Done* in Developement stage
• Once the granted user promote the application to the next level, the proceeding promotion should be able to done via the next relevant user role. E.g., Once the developer promotes the application to the staging, it will go to the testing stage and the Governance page will show that the version is in the Testing stage, whereas the Promote button will be disabled since the Developer is restricted promoting it from Testing stage to Staging. But if the testing user logged in to the system and get on to the Governance tab of a particular application version, he or she will be able to see it is in Testing stage and Promote it to the next staging stage or demote it to the development stage.
• A relevant user can view the version only in their stage and the ones they have promoted in to the next stage. E.g., A test user can view only the versions in the Testing stage and the staging stage. Upfront stage options will be disabled.
• This will also have an option to download logs for the relevant application depends on the user role. E.g., A test user can download logs of testing and staging environment.
  
  
  
                                                        Governance View
  
  

Track Issues

• User will be able to click on the link provided in this page and login to the Redmine to report and track issues by providing their credentials.
• Summary of the issues reported, along with the status will be displayed in this section.

Configure Resources

• Database Configurations, Datasources, Properties and API information will be configured using this section.
• Each user role will be able to define their databases , properties etc using this section according to their environment.
• Once a developer configures these information, the relevant user will be able to use the same datasource and configure their environment just by editing the URL, username and password.
• Each user will be able to view their configurations and the upfront stage configurations as a usability feature.
  Exceptional : App Owner will not be able to view the production configurations/resources. That will only be available for the Dev ops.
  
  

  

                                           Configure Resource View