1.3 - Development Lifecycle for CMS Based Development

Overview:

Once project requirements and design stages are complete, the development lifecycle covers four main remaining stages:

1. Implementation (coding)

2. Testing

3. Deployment

4. Maintenance (updates)

These steps will be handled differently depending on whether you choose the CMS environment, or the file-based development environment. In most cases you will want to choose the new file-based development environment, as this will offer you much more flexibility.

For maintaining existing projects, however, you may still need to use the CMS system.

Implementation (coding):

When using the CMS environment, all development is done within the web based CMS system: the Interaction Manager.

Within the Interaction Manager you’ll be able to use the built-in code editor to write both server side and client side code, as well as managing CSS style sheets, uploading static assets such as images and script libraries, and also access our point and click forms builder.

Everything you need can be handled within the web based CMS system.

The development environment supports jQuery and jQueryMobile for client side frameworks, plus PHP for server side code.

Testing:

As the development environment is coupled tightly with the Blink Mobility Platform, to run code successfully, the code will need to be run from within the answerSpace (as opposed to on a developer’s machine). Because of this, testing ability for the CMS environment isn’t as accessible as the file-based development environment.

Testing is most commonly done manually within this environment by the developer.

Deployment:

Being a fully hosted service, including for code editing, deployment is done instantly and automatically as soon as you click the “Save” button.

This allows for rapid iteration for testing and CMS based development.

Moving a project from a dev environment to testing or UAT, and then production can be done via exporting your answerSpace (as a ZIP file) from one environment and importing into the next.

For projects delivered within an appshell, the new changes will take effect the next time the user restarts their app. There is no need to re-deploy appshells (unless you modify native functionality, such as adding new native plugins or icons, etc.).

Maintenance (updates):

Maintenance of a project is essentially handled through the same two steps above - a development environment can be edited when needed, then exported and imported into a test or UAT environment when ready, and then finally pushed into production.

Having the three answerSpaces allows you to handle ongoing maintenance in separate environments, meaning it won’t affect your production project.

Next:

1.4 - Development Lifecycle for File-based Development