Browse Prior Art Database

Cloud based simultaneous multi-platform development environment Disclosure Number: IPCOM000238991D
Publication Date: 2014-Sep-30
Document File: 3 page(s) / 148K

Publishing Venue

The Prior Art Database


A process to provision required environments, then asynchronously send realtime changes made in an IDE to multiple platforms, run a build/test cycle and feedback results to the IDE where they are aggregated and displayed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 3

Cloud based simultaneous multi-platform development environment


    Developing multi-platform code in current IDEs does not give live feedback of build/test results on changes made in workspace. Generally, the process of development for native languages, such as C/C++, across multiple platforms is as follows:

    1) Write the code on whichever platform the developer has their IDE workspace on. At this stage the developer must take into account any differences in code that are required for the other platforms the product is build on without any feedback.

2) Build the code on all required platforms.

3) Test the code on all required platforms.

    4) If there are failures in step 2 or 3, go to 1 to make changes that fix the discovered issues. Iterate until all issues are resolved across all platforms.

    This long iterative process extends development time and turnaround for build/test results when developing native languages across multiple platforms. Known solutions and drawbacks:
There exist many cloud based IDEs, such as the following: he-enterprise/

    These kind of IDEs move the development environment into the cloud, but only have support for platform agnostic languages i.e. they do not provide support for platform specific languages, and thus do not have the environment required for such development.

    Single platform development is possible by running an IDE on the given platform, such as Eclipse running on Linux if Linux is the only OS a product supports. This lacks capability to build for other OS/arch combinations, so feedback falls back to the separate build/test cycle described above.

    Cross-compilation is possible, where one platform can build code for another, but this is generally a complex environment to setup and has restrictions on which platforms can be cross-compiled e.g. Windows development machine cannot build z/OS binaries.

    Build farms can extract code from source repositories and build/test at regular intervals. This is an automation of steps 2 and 3 above, and has the drawback that it is not incrementally linked to live changes in the IDE - changes must be submitted into a build system to receive results - and the cycle from change to build/test result is typically much longer than desired for a single incremental change.

Core novelty:

    Ability to provision required environments then asynchronously send realtime changes in IDE to multiple platforms, run a build/test cycle and feedback results...