Releasing new developers
• Mark Eschbach
We’ve got a few new engineers and some extra helpers which is great. However all the new guys are trying to defualt to using Git Flow. I’m actually a little horrified people aren’t asking questions and just make assumptions about the build engineering and release processes. I think this is good feedback we need to add this to onboarding.
Anyway, while trying to get something into a release I merged a branch based on a future release. This is unfortunate becuase it deployed the migrations for the future release onto the target environment. It’s actually not much different than what would happen in a production roll back, however I’m a little saddened by my oversight. The basic rule should be if the intended release version and the source version don’t match a build should fail early in the process as opposed to only realizing it in it’s released environment.
I’ve already built a small library around the release setup and even the project specific sections are properly separated. I was originally going to decompose the version numbers to verify the correct source release matched each version component (
majore.minor) of the branch, however I realized I only need to preprend the release specifier.
Turns out I’ve already implemented this in place. Underlying problem was related to not checking out the working branch a head of time. Since this wasn’t expressly needed for this check I opted to fall back on the variable
TRAVIS_BRANCH and verify that makes sense. Shouldn’t be a problem going forward.