The structure of the development with SVN on bpm'online platform is described on the Figure 1.
Figure 1 - Organizing development process with SVN in bpm'online
1. Developers work independently in their local environments and databases. The developers should not work with the same schema at the same time. They should work with different schemes.
2.After completing a task, a developer commits the dev package with the new functionality to SVN. Each task should not take more than 2-4 development hours.
3.The developer updates the dev package on the pre-production application from SVN. The developer makes sure that all the newly created objects, modules, data, and scripts appear in the pre-production application.
The developer generates source code for every uploaded item. After that the developer compiles the system "for modified items".The bound data and sql scripts should be installed manually.
After all changes are successfully applied to the pre-production environment, the implemented functionality should be tested. If the testing is not successful the developer should rollback the commit in SVN and restore the pre-production application from a backup. Update the pre-production application from SVN after restoring if it's necessary. If there is no backup, then restore the application from an out-of-the-box system and install the package from SVN from scratch.
4. If the newly created functionality works properly, then the task can be considered as "Done".
5. Every 3-10 tasks the development team should deliver the package from the local pre-production application to the cloud one via import/export package. The cloud pre-production application should not be connected to SVN.
Note: The cloud pre-production is not required. If the functionality is simple, then it's possible to transfer it directly to the cloud production via import/export packages. Please create a backup of the production application before transferring.
6. If the testing of the new functionality was successful then the packages are ready for installing to the production environment via import/export
Nice explanation!
One quick question: Why should we export the package from cloud pre-production (6) to install it into production? Is it possible to install the original package exported from pre-production (4)?
Thank you
It's possible to avoid the cloud pre-production. However in this way the process will be less stable.
Mohamed Ouederni,
I see no different about the package exported from pre-production and cloud pre-production, as same as your view. The worst case depends on how you manage your release process. If there are 2 teams working independently (implementation team and production deployment team), then the best trusted source is the package exported from cloud pre-production environment, where the production deployment team already inspected and qualified the package content. If the production deployment team is also controlling the installing package, then they can use the same package for production.