YAML Specs approach and Best Practices

[Sean Conlon]

We have an on-prem Bamboo and Bitbucket setup, and we are looking to introduce Specs into our environment.  We have about 60 Projects, and close to 200 Build Plans (all Java). 

However, we see the pros and cons of using Java Specs and Yaml Specs, but we are looking for some guidance and best practices on how to use each one, which will help us decide which setup fits us best.

If we use YAML, should we (1) include the YAML Spec file in a given project?  Or should we (2) have a single Bitbucket repository that contains all of the the YAML files? 

In scenario 1, how do we prevent developers from disabling certain features that we (DevOps Team) want to enforce?

In scenario 2, how do we make updates to a single build plan without impacting all of the projects included in that Linked Repo?  Is Bamboo smart enough to know which Plan was updated and only impact that Plan?

Any direction on best practices for both Java Specs and YAML Specs would be greatly appreciated. 

[Marcin Gardias]

If you use YAML, storing Specs with the project is the only option, so if you want scenario 2, you need Java Specs. 

In both scenarios Bamboo will have to compile all the specs it finds, but will only update items that actually change.

One benefit of scenario 1 vs 2, is that in scenario 1, assuming you use Bitbucket, Specs for branches feature is active, in scenario 2 it is not and you get 'regular' plan branches. What that means that in scenario 1 you get way more options to customize your plan branches.

Lastly, since you are a Java shop, I strongly recommend using Java Specs. I find Java Specs way easier to work with. Especially, that you have many plans and probably would like to be able to extract common configuration patterns into some kind of shared utilities.