I work in a small team of developers who all collaborate on several Zend PHP projects. We are using Mercurial with a collection of upstream repositories, as well as Jenkins for centralized testing and health reports. We want to implement a shared library of common classes, but are struggling with finding a workflow that works well with our current environment.
Currently, each project contains a structure like this:
- application (project specific code) - build (temporary files generated by each build) - library (code used by multiple projects) - OurLibrary (our company’s shared codebase) - Zend (external libraries) - tests (test code specific to this project)
The library folder is excluded from testing, and so we have created a project specifically for running unit tests against the shared library. This decision was made primarily to avoid deploying the test classes by accident, something which can largely be mitigated by a modification to the automated build process, but also because we felt that it was preferable to keep the library lightweight.
We are including the library in each project as a Mercurial sub-repo. This means that changes pushed into the library from a developer working on ProjectA wil not automatically propagate to ProjectB (good) but will also not propagate to the library testing project (bad), and Jenkins will therefore not automatically warn us of potentially breaking code in the library (very bad).
An ideal situation would be that developers can commit changes to the library from any project, and that our automated tools would then run the latest library tests against the latest library code. Furthermore, this should not result in a version conflict when a developer pulls a new version of the library tests.
Is there an established methodology for this kind of workflow, or should we look into structuring our working practises a little differently before we fully commit ourselves to sub-repos?