Difference between revisions of "Development Techniques in the AgileApps Cloud"
imported>Aeric |
Wikieditor (talk | contribs) Â |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
:{| border="1" align="right" cellpadding="5" cellspacing="1" | |||
| | |||
* [[Customizing the ServiceDesk application in the AgileApps Cloudâ˘|Previous Article]] | |||
* [[Client Certificate Authentication (aka âCustom Headersâ) in a private AgileApps Cloud|Next Article]] | |||
* [[Article Index|Back to Article Index]] | |||
|} | |||
==== IDEs and Unit Testing ==== | ==== IDEs and Unit Testing ==== | ||
===== Developing Classes and Pages with the Eclipse Plug-in ===== | ===== Developing Classes and Pages with the Eclipse Plug-in ===== | ||
| Line 13: | Line 20: | ||
:Tests on all classes can be run at one time, as well: | :Tests on all classes can be run at one time, as well: | ||
:[[File:Yd.png]] | :[[File:Yd.png]] | ||
:Learn more: http:// | :Learn more: http://agileappscloud.info/aawiki/Unit_Test_Framework | ||
==== Development Models ==== | ==== Development Models ==== | ||
===== Cloud Development Model ===== | ===== 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. | 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.<br><br>[[File:Yye.png]]<br><br> | ||
: 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. | |||
: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 | Â | ||
===== Sandbox Development Model ===== | ===== 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. | 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:// | :Learn more: http://agileappscloud.info/aawiki/Sandboxes | ||
==== Deployment ==== | ==== Deployment ==== | ||
===== Publishing to the Community Marketplace ===== | ===== Publishing to the Community Marketplace ===== | ||
After a fully tested package | 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:// | :Learn more: http://agileappscloud.info/aawiki/Community_Marketplace | ||
 | |||
===== Deploying Packages to Tenants and Others ===== | ===== 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 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. | ||
| Line 34: | Line 42: | ||
:[[File:Yg.png]] | :[[File:Yg.png]] | ||
: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. | :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:// | :Learn more: http://agileappscloud.info/aawiki/Packages#Deploy_a_Package | ||
==== Tracing Issues in a Production Environment ==== | ==== Tracing Issues in a Production Environment ==== | ||
| Line 40: | Line 48: | ||
:[[File:Yh.png]] | :[[File:Yh.png]] | ||
:Learn more: | :Learn more: | ||
::* http:// | ::* http://agileappscloud.info/aawiki/Proxy_Login_as_this_User | ||
::* http:// | ::* http://agileappscloud.info/aawiki/Developer_Configuration | ||
 | |||
==== Change Control ==== | ==== 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. | 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. | ||
:{| border="0" align="left" cellpadding="5" cellspacing="1" | |||
| | |||
[[Customizing the ServiceDesk application in the AgileApps Cloudâ˘|Previous Article]] | |||
|} | |||
:{| border="0" align="right" cellpadding="5" cellspacing="1" | |||
| | |||
[[Client Certificate Authentication (aka âCustom Headersâ) in a private AgileApps Cloud|Next Article]] | |||
|} | |||
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |||
:{| border="0" align="Center" cellpadding="5" cellspacing="1" | |||
| | |||
[[Article Index|Back to Article Index]] | |||
|} | |||
Latest revision as of 07:08, 27 December 2022
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.