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