Is there any way to avoid being affected by an master merge from my colleagues' modules
The technology diagram(including some Chinese but matters little) is:
- Pip install doesn't checkout correct branch
- How to hide the access keys of aws amazon productively in VagrantFile file
- Cannot checkout git ssh repository with vcsrepo
- write puppet config to clone github repo
- How do I set Windows environment paths in current Puppet session?
- Manage Keys with Puppet for puppet-vcsrepo
Common configurations like packages source list,dns servers ,and system related files is coding into puppet modules named with pkgmgr,networkmgr and sysenv.They are developing ,testing and releasing in different branches then pushed to /modules/env(branch)/common directory on puppet master node. On the other hand,we have many projects having their own configurations,including or declaring common modules,coding into a module named after project name and then copied to modules/env(branch)/projects in the same way.
Servers in every project acting as puppet agent can be set a specific puppet environment like production,testing.For example when the production environment is selected, the resources from modules defined in /modules/production/common and /modules/production/projects/project_A will be deployed.
Common modules is maintained by another apartment , any update merged to master branch will affect our projects servers in production environment.Is there any way to satisfy:
1 Some of our projects servers do not want any update anymore before they are offline
2 Any change to common modules will generate a tagged snapshot like version and can be selected by our project positively
I know is hard to release puppet module in version like other offline softwares,but any way else to satisfy the two requirements elegantly?
One Solution collect form web for “Is there any way to avoid being affected by an master merge from my colleagues' modules”
Release management of software can be tricky with lots of teams.
My recommendation is don’t use the same repository, if you can use one repository per module (although this can introduce quite a bit of overhead). Instead you can just use multiple git repositories and vendor your companies “common” modules in using say librarian-puppet.