0

What is the ideal way to structure inherited toolkit projects?

Addison Bath

July 28, 2015 16:23

None

Follow

What is the ideal way to structure inherited toolkit projects?  I would like to maintain one toolkit project where division level changes are maintained.  This project would have all apps, engines, hooks, and yml that would be shared across projects for the division.  If an individual project needed a customization, we would want to override the app/engine/hook/yml only where the change is needed.

 

Ideally, copies of all the apps/engines would NOT be maintained in each individual project.  Only project specific customization.  Also, it would be good if this division level project could inherit from a studio level.

 

All input welcome

• Facebook
• Twitter
• LinkedIn

1 comment

• 0
  
  Permanently deleted user July 28, 2015 19:05

  Hello Addison!

  This is a really great question and something that some of our clients have started doing.

  The short answer is that this is partially possible through various uses of the @include statement in configurations etc. I have just updated the documentation we have explaining how to manage your config with some better structure and more detailed and pragmatic advice.

  But while there are some ways and tricks to handle global configurations in toolkit, the reality is still unfortunately that the configurations are very much on a per project basis. Each project is maintained as a separate unit. This can make it cumbersome if you need to manage multiple projects at once, or if you have a lot of small projects. Both global @includes and git based shared configurations are ways to make it easier to share configurations between projects, however we are well aware that while they give you a lot of flexibility, it is still fairly complex to set up a global or inheritance based configurations.

  This is something that we have been discussing for a while internally, and we are hoping to be able to do a version 2 of our config at some stage, hopefully not in the too distant future. In this pass we would address a lot of config related things and try to make the structure of configurations go beyond projects and make it more easily maintainable. We are at a point where we have been getting a lot of feedback about the existing configuration and we feel that the timing is right to try to collate all that feedback into a strategy for a v2.

  Let me know if there is anything specific we can help with and we'll be happy to assist!

  Manne