Restructuring projects
Many reasons exist for why sites decide to restructure projects; the following are a few:
- The direction of your product has changed and you must remove subprojects from the hierarchy.
- A project has grown too large, and you want to split it into smaller parts.
- Your team added lots of new functionality to your product, and you must add subprojects to the hierarchy.
- A different team now is responsible for part of the software, and you want to move it into a separate project.
- Your team decided to wait and include a disruptive change to your product in the next release. Now you must unuse a subproject from the hierarchy.
- You want to add an external project.
- You want to add an installation project.
When you restructure a project, change the make files, the build process, and all automated jobs to reflect the changes you have made.
Apply the changes to both the integration testing project hierarchy and the system testing project hierarchy. Update the integration testing project hierarchy first. Apply the change to your system testing project hierarchy by checking out any new projects, then updating to bring in the changes.
Additionally, when you restructure a project, perform an update and then rebuild the project hierarchy to ensure the integrity of your application. For the integration testing project, your usual short test suite suffices. For the system testing project, the SQE team might retest your application.