Best solution for maintaining package structure with large team members
Hi,
We are member of 7 to 8 developers who are going to be working in large enterprise project in BPM online. Could someone please advise which is the best approach to maintain the package structure?
1) Single package for the whole development
2) Each package for each developer
3) Section wise packages.
Thanks,
Mohamed.
Like
Halludeen,
A package structure is not related to the development team. It always should be a single package for the whole development.
The main idea is that everything should be bound to the package. You should be able to deploy an out-of-the-box instance, install the package and get the complete project functionality ready to go live.
All developers should work in the same package. Each of them should have his or her local instance.
All project functionality should be decomposed on small tasks. Developers should be able to complete a task for 2-3 hours.
After completing a task a developer should commit the functionality to SVN. Check the committed data in the repository, make sure that everything that he or she did for the task appeared the repository (schemes, data bindings, objects etc) . Then update pre-production from the repository. make sure that all mentioned data appeared in the pre-production instance. Generate source codes for the installed data, publish installed objects. Test the functionality on the client end. Transfer the completed task to the project manager for further testing.
If something wrong (not all data appeared in svn, something missed on the pre-production, compilation errors etc), roll back the commit in SVN, install the package from SVN (install means that the package will be deleted and created again. update means that the package will be merged), generate source code for all items in the package, compile all. If the pre-production instance is broken, then restore it from backup and install the package from SVN again then generate and compile again, make sure that it works. Then resolve the issue on the local dev instance.
If local dev instance is broken, a developer should be able to create a copy of the pre-production, deploy it locally and use it as a new local dev instance. Additionally, any time you should be able to take an out-of-the-box application, install the package on it and get a ready-to-use pre-production instance.
Sometimes it's suitable to create 2 dev packages. This way they should be completely independent. For example, it can be a dev package with all project functionality and a test package with some test data only for testing. Anyway, all project functionality should be in the dev package and it should work without any other data except the one that exists in an out-of-the-box application.
Transferring packages from pre-production to production instance should be done by export the package/installing the package. Not by SVN. SVN should not be connected to a production instance. It's not recommended to connect SVN to cloud instances at all. Sometimes it's a good idea to create 2 pre-production instances. First locally and the second in the cloud.
Please note that all data required for the package functionality should be bound to the package. In order to bind data correctly, we recommend inserting/updating it via SQL queries and bind the queries to the package in the "SQL scripts" tab of the configuration
Dear Mohamed,
We would recommend using separate instance for each developer and SVN to connect changes between applications. You can read more on Academy: https://academy.bpmonline.com/documents/technic-sdk/7-13/organizing-development-environment
Best regards,
Angela
Halludeen,
A package structure is not related to the development team. It always should be a single package for the whole development.
The main idea is that everything should be bound to the package. You should be able to deploy an out-of-the-box instance, install the package and get the complete project functionality ready to go live.
All developers should work in the same package. Each of them should have his or her local instance.
All project functionality should be decomposed on small tasks. Developers should be able to complete a task for 2-3 hours.
After completing a task a developer should commit the functionality to SVN. Check the committed data in the repository, make sure that everything that he or she did for the task appeared the repository (schemes, data bindings, objects etc) . Then update pre-production from the repository. make sure that all mentioned data appeared in the pre-production instance. Generate source codes for the installed data, publish installed objects. Test the functionality on the client end. Transfer the completed task to the project manager for further testing.
If something wrong (not all data appeared in svn, something missed on the pre-production, compilation errors etc), roll back the commit in SVN, install the package from SVN (install means that the package will be deleted and created again. update means that the package will be merged), generate source code for all items in the package, compile all. If the pre-production instance is broken, then restore it from backup and install the package from SVN again then generate and compile again, make sure that it works. Then resolve the issue on the local dev instance.
If local dev instance is broken, a developer should be able to create a copy of the pre-production, deploy it locally and use it as a new local dev instance. Additionally, any time you should be able to take an out-of-the-box application, install the package on it and get a ready-to-use pre-production instance.
Sometimes it's suitable to create 2 dev packages. This way they should be completely independent. For example, it can be a dev package with all project functionality and a test package with some test data only for testing. Anyway, all project functionality should be in the dev package and it should work without any other data except the one that exists in an out-of-the-box application.
Transferring packages from pre-production to production instance should be done by export the package/installing the package. Not by SVN. SVN should not be connected to a production instance. It's not recommended to connect SVN to cloud instances at all. Sometimes it's a good idea to create 2 pre-production instances. First locally and the second in the cloud.
Please note that all data required for the package functionality should be bound to the package. In order to bind data correctly, we recommend inserting/updating it via SQL queries and bind the queries to the package in the "SQL scripts" tab of the configuration