Where do you store your build and deploy scripts?
I've seen multiple ways of dealing with this:
- Keeping them within the Jenkins (or any other CI) Job.
- Keeping them with the actual code all together.
- Keeping them in a separate repository, as sort of a cookbook.
Whilst 1. is a complete no-go, as it is bypassing any kind of QC, 2. & 3. to my mind are valid options. I would probably lean more towards 2., as it is brings everything into one place. If everything is in one place, it is usually easier to maintain.
The only thing that could be against the 2. option is that if you change the build and deploy scripts, you technically need to bump up your projects version, which triggers a release/redeploy, etc.
I believe that is a small price to pay, compared to having n different repos, but option 3. could solve this.
What are your thoughts about this? Do you have a different strategy?
Top comments (5)
Forcing a version bump when the build process changes is actually a good thing. In fact, even if you have the build scripts separated from the code, you should still be mandating a version bump on the first build after changing the build scripts.
Quite simply, it's insanely easy for a seemingly innocuous change to the build process to generate completely different code or introduce subtle errors in the application (trivial examples include switching between GCC and clang, enabling or disabling LTO, or tweaking the optimization level of a build). Dealing with the fallout from such a situation is a whole lot easier when you can just look at the version and say 'Oh, that's version x.y.z, it has a bug, you need to either upgrade or downgrade to avoid it.'.
As for deployment scripts, I'm of the opinion that it doesn't matter much, provided that your app treats them like a black box (that is, it only cares about the end-state of the deployment, not the intermediary steps).
We currently using no. 2 but there's plan to move into 3. Basically the plan is, for every
project_namewe will have separate repoproject_name_deploythat will house all the deployment scripts for that project. Changes to deploy scripts not necessarily changes to the app itself. We will still deploying app v2.21, just different way. So that doesn't warrant a bump to app v2.22. Having separate repo also allow ops team to iterate on deploying mechanism independently of the app development.I really don't see any problem with option two and it's actually what I do in real life. My team seems to like it very much either.
Good to know! So.. if your build file changes but nothing of your code/business logic you still bump up the version, tag it, etc.?
Well, I guess that could happen :)
But as others have stated, I don't see this as a problem, since we should know asap whether those changes affected our deploy anyway.
That said, we don't deploy every commit. So we could simply choose not to deploy a change that only touched infrastructural stuff.