Showing posts with label appfactory. Show all posts
Showing posts with label appfactory. Show all posts

Sunday, June 23, 2013

How to create a MySQL database and a datasource using WSO2 Appfactory


With the beta release of WSO2 App factory, it enables you to create a database and datasource for the applications you create using App Factory.
Current latest version supports MySQL.
This blog post explains you steps to create a database and a datasource and how to point them in a Web application (WAR) created using WSO2 App Factory.

For more information on WSO2 App Factory :



To create a WAR/ Web app supports the datasource

  1. Registered user can successfully login to WSO2 app factory and create a web application. As an example I will be creating a web application named ColourFindApp.


    Application Creation

  2. Once I created the application, I will be assigning user roles for the application using the Team page.
  3. Then a developer or the app owner which has developer rights will be checking out the source code using GIT and do the necessary code level changes via Developer studio and then commit the code.
    http://ushanib.blogspot.com/2013/02/steps-to-checkout-and-commit-wso2.html
  4. As an example assume in my source code, I refer my datasource as colour. So the sample code in my application source code will be something like below.
    E.g.,

    …............
      Hashtable hashtable = new Hashtable();  
 hashtable.put("java.naming.factory.initial","org.wso2.carbon.tomcat.jndi.CarbonJavaURLContextFactory");  
 Context initContext = new InitialContext(hashtable);  
 ds = (DataSource) initContext.lookup("jdbc/colour");  
 Connection conn = ds.getConnection();  
 Statement statement = conn.createStatement();   
        …............

  1. So the datasource I will be creating should be named as colour.
Databases Permission level

User Role Permission
App Owner Can create and configure databases in Development, Testing and Staging
Developer Can create and configure databases in Development and Testing environments
QA/Tester Can create and configure databases in Testing and Staging environments
Dev-Ops Can create and configure databases in Staging and Production environments
  1. A user can login to the system and select the resource section to create a database.
  2. User can create the database as per the above permission. Visibility of Database environment will be as above user role permission. User will be able to select the environment from the drop down. DB User and template can be created inline or separately and select it form the drop down.
  3. Created users and the templates for each environment will be loaded depends on the selected database environment.


                                              Database Creation


    Datasource Permission Level
User Role Permission
App Owner Can create and edit datsources in Development, Testing and Staging
Developer Can create and edit datasources in Development and Testing environments
QA/Tester Can configure created datasources in Testing and Staging environments
Dev-Ops Can configure created datadources in Staging and Production environments
  1. App owner can create a datasource and provide the database url created initially. E.g., I create a database named COL_DB and Datasource as colour.
  2. Then a datasource will be copied in to testing and staging as well along with the provided database URL. E.g., If I provide the database URL of the development stage it will copy the database URL of development stage in testing and staging as well.
    E.g.,
    jdbc:mysql://rss.dev.appfactorypreview.wso2.com:3306/COL_DB

                                Shows the datasources visibility as an APP Owner

  3. If a developer logs in to the system, he or she will see the datasources created in Dveloement and testing stages.
  4. A Developer or a testing user can create another database in testing environment and select the datasource created and the stage as Testing and provide the newly created database URL of the testing stage. E.g., Database created in testing : COL_DB in testing storage server and select the colour as the datasource and the stage as testing and the testing DB URL and update it.

    E.g.,
    jdbc:mysql://rss.test.appfactorypreview.wso2.com:3306/COL_DB
  5. This will enable the different users to easily update their datasource with their desired database location and test the application.
  6. Depends on the stage selected, existing database URL and attached users will be loaded.
  7. If not a developer or a tester can test their application with the datasource created initially which points to the database in the development without editing and configuring it to the different environment.
  8. When promoting the application in to proceeding stage it will refer the database pointed to the promoted environment.
  9. Only Dev Ops have permission to configure the production environment. Therefore DevOps will have to select the stage as Production and provide the database URL accordingly.

Friday, February 15, 2013

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.
  • 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

Wednesday, February 6, 2013

Steps to checkout and commit a WSO2 Appfactory GIT application.

WSO2 App Factory is a platform for managed application development for the entire lifecycle of applications. Supporting you from cradle to grave, you can create, develop, test, deploy to production and retire applications with a single click. Applications can be web applications to mobile apps that require any type of middleware to run on including even non-Java and non-WSO2 technologies.
For more information : 
 http://blog.cobia.net/cobiacomm/2012/04/16/what-is-wso2-appfactory/

Following steps will be useful for a user who is using git as the repository and to checkout the code of the created application and the steps till it is committed.

For The Ubuntu Environment

  1. First step should be installing GIT in to your machine. Therefore the following command should be executed.
    Command : $ sudo apt-get install git

  2. Check whether GIT is available in your machine now.
    Command : $ git init
    Response : Initialized empty Git repository in /home/../.git/

  3. Create a folder to archive the Git projects in to one location in your repository.
    Command : $ mkdir GITPROJECTS

  4. Add all the Git projects in to your repository by the following command.
    Command : GITPROJECTS$ git add .

  5. To get the GIT to Accept the certificate, type the following command.
    Command : GITPROJECTS$ export GIT_SSL_NO_VERIFY=1
    On Windows : (Right click on My Computer -> Properties -> Advanced System settings -> Environment Variables
    Add variable GIT_SSL_NO_VERIFY with value 1)

  6. To clone the particular project in to your repository, copy the (Clone/Check out) repository URL in the application Dashboard or the Repository page of the App Factory. (Only if you have developer or App Owner rights)
         Command : GITPROJECTS$ git clone https://git.appfactorypreview.wso2.com/git/MyApp.git
         Response : Cloning into 'MyApp'...
         Username for 'https://git.appfactorypreview.wso2.com': <Developer's username> e.g., ushani@wso2.com
         Password for 'https://ushani@wso2.com@git.appfactorypreview.wso2.com': *****
         remote: Counting objects: 23, done
         remote: Finding sources: 100% (23/23)
         remote: Getting sizes: 100% (14/14)
         remote: Compressing objects: 100% (13/13)
         remote: Total 23 (delta 4), reused 23 (delta 4)
         Unpacking objects: 100% (23/23), done.

  1. List down and check the project
    Command : GITPROJECTS$ ls
    Response : MyApp

  2. Go inside the project and check for the available branches in the repository
    Command : GITPROJECTS$ cd MyApp
    Command : MyApp$ git branch -r
    Response : origin/1.0.0
    origin/2.0.0
    origin/3.0.0
    origin/4.0.0
    origin/HEAD -> origin/master
    origin/master 

  3. To list down the local branches that you have, following command can be executed
    Command : MyApp$ git branch
    Response : * master
(* master means the trunk. The branch that you are currently working on will have a star next to it and if you have coloring turned on, will show the current branch in green)

  1. To create other branches in the local repository, following command should be executed.
    Command : MyApp$ git branch <version name>
                e.g, git branch 1.0.0 
                 
  2. Now check the created branch
    Command : MyApp$ git branch
    Response : 1.0.0
          * master

  3. To switch to 1.0.0, following command should be executed to check out the relevant code in to your local repository
    Command : MyApp$ git checkout 1.0.0
    Response : Switched to branch '1.0.0'
(*Steps 10 and 11 can be executed together by executing “git checkout -b 1.0.0”. Then it will branch out 1.0.0 and switch to it. When you type checkout and give the branch name, the source code you have in your local repository will be the given version's source code that is in the App Factory repository. If you type “git branch” you should see the 11th step response)

  1. Now it is the coding time. You can import your project in to a specific IDE (E.g., Eclipse) and do coding.

  2. You can install a toolkit which helps you to show the changes you have done in to your code by installing GITK (Generalized Interface Toolkit - GITK). To install, following command can be executed.
    Command : Downloads$ sudo apt-get install gitk
    (This step can be done as the 2nd step after installing git in your machine. For more reference on git, follow this manual on https://www.kernel.org/pub/software/scm/git/docs/gitk.html)

  3. After doing code level changes, when you type the following command, GIT window will be opened with the changes or mentioning the about the changes that you have to commit
    Command : MyApp$ gitk 
     
  4. By executing the following command you can view the changes in you terminal.
    Command : MyApp$ git diff

  5. To add all the changes following command should be executed.
    Command : MyApp$ git add *

  6. Using gitk, you can view the changes and the difference in a graphical interface by selecting the particular file or folder. (Use the manual in step 14 for more information)

  7. Now it is the time to commit if your build passes locally. Execute the following command to commit your code. Command : MyApp$ git commit -am "Committing changes"
    Response : ([1.0.0 9b736e4] Committing changes
    Committer: ushani <ushani@ushani...>
    Your name and email address were configured automatically based
    on your username and hostname. Please check that they are accurate.
    You can suppress this message by setting them explicitly:
    git config --global user.name "Your Name"
    git config --global user.email you@example.com
    After doing this, you may fix the identity used for this commit with:
    git commit --amend --reset-author
    1 file changed, 2 insertions(+) )
    (For more information on git commits, rollbacks, applying etc, use the following guide. http://gitref.org/basic/)


  8. To push the commits, execute, git push <remote>, where <remote> is the current branch’s remote (or origin, if no remote is configured for the current branch.
    Command : MyApp$ git push origin remotes/origin/1.0.0

    (For more information on git commits, rollbacks, applying etc, use the following guide. http://www.kernel.org/pub/software/scm/git/docs/git-push.html )
    Response :Username for 'https://git.appfactorypreview.wso2.com': ushani@wso2.com
    Password for 'https://ushani@wso2.com@git.appfactorypreview.wso2.com': *****
    remote: Updating references: 100% (1/1)
    To https://git.appfactorypreview.wso2.com/git/MyApp.git
    * [new branch] origin/1.0.0 -> origin/1.0.0

  9. You can pull the committed code by executing the following command to verify the changes are committed. (But not necessary)
    Command : MyApp$ git pull origin remotes/origin/1.0.0 
     
  10. Now in App factory, if you have selected the Auto Build and Auto Deploy options for the particular branch version, once you do a commit, within 6 minutes the latest version should be built and deployed in the cloud. Otherwise you have to manually build and deploy it.

  11. Now you can click on the Launch link and see it in the Developer's environment and if it is fine to go ahead, you can promote it to testing stage by the Governance tab.