Development Techniques in the AgileApps Cloud

IDEs and Unit Testing

Developing Classes and Pages with the Eclipse Plug-in

Interactive Development Environments (IDEs) make development easier. Developers can use the Eclipse plug-in to develop Classes and Pages:

Debugging with the Eclipse Plug-in

AgileApps allows classes and pages to be debugged using Eclipse Plugin in development mode. Standard debugging configuration in Eclipse is used for this purpose. The project should be configured to build automatically.

Note: Sometimes the code optimization done by Eclipse is different than the optimization done by the JVM in tomcat. Source code linking issues can result. To work around that problem, make a small change to the source code while debugging (for example, by adding/removing a space) and save. The Eclipse debugger will immediately link to the source code correctly, allowing developers to step through the code as well as hot-deploy any changes.

Unit Testing

Developers can use the integrated unit testing environment in AgileApps to create and launch unit tests. Here are the results from running the tests defined in a single class:

Tests on all classes can be run at one time, as well:

Learn more: http://agileappscloud.info/aawiki/Unit_Test_Framework

Development Models

Cloud Development Model

In the Cloud Development model all the developers are located on the same tenancy in AgileApps. They all have User IDs in a shared development environment.

After developers have created the first version of their application, they create a package containing the application and publish it to the QA tenancy. After the QA certifies the package it can be promoted to staging and production tenancies or published in the catalog. Developers also have the option to download the package ZIP file and check it into their organization’s version control repository.

Sandbox Development Model

In the sandbox model, developers and testers have their own tenancy in which to carry out their operations. Packages are published following defined paths, so that developers can share developments with each other, for example, and so they can publish to a common Q/A tenancy—but only the Q/A tenancy is allowed to publish an application package to the production tenancy.

Learn more: http://agileappscloud.info/aawiki/Sandboxes

Deployment

Publishing to the Community Marketplace

After a fully tested package is loaded into the production tenancy, the developer has an option to use the AgileApps application-listing management system to create a listing request. As part of the request, the developer can provide information for the listing. Once the request is approved, the application appears in the marketplace.

Learn more: http://agileappscloud.info/aawiki/Community_Marketplace

Deploying Packages to Tenants and Others

Packages have multiple deployment options. As shown here, a package zip-file can be downloaded directly, the link can be copied and placed in a location for others to find, or tenants who have installed the package can be upgraded directly, by choosing the Deploy option.

Packages can be directly deployed to all tenants who have subscribed to the package, to selected tenant subscribers, or to selected sandbox tenants, either immediately or at a scheduled time in the future:

REST APIs can also be used to submit the deployment job. The API Call returns a Job ID, which can used to check the status of the job. At the end of the deployment process, the system sends summary deployment information to the job submitter.

Learn more: http://agileappscloud.info/aawiki/Packages#Deploy_a_Package

Tracing Issues in a Production Environment

Once Applications have been deployed into customer tenancies, it is possible for developers to “proxy-login” to those tenancies using the built-in Customer Support system. Once there, developers can enable a variety of debug-log levels.

Learn more:

• http://agileappslive.info/wiki/Proxy_Login_as_this_User
• http://agileappslive.info/wiki/Developer_Configuration

Change Control

AgileApps can be configured to allow application change rights for authorized system roles. For example, some roles might be able to add Java classes, some may only be able to add or customize layouts.