3

Atm we're merging everything straight up to production because we only have our first client going live tomorrow. No problem except for the fact boss is using production to give demos to clients already. And so some JavaScript change that broke search made it to production and cropped up during a demo. So what does boss do? Call HR/support and yell at her that everything which works needs to keep working. Which is fair if we were live and we go back to merging to production being rare. So HR/support was in tears during our meeting where we were taking about the new live branch structure. GG boss. We consoled HR/support but really boss man knew how we work but ignored it.

Question for everyone though: what can we use or do to prevent changes to more general JavaScript breaking things around the code? We talked about unit tests and maybe code linters but is there more? Because it seems now might be the time to improve our working and even get budgets for tools.

Comments
  • 2
    The only way around this is to properly implement a CI/CD pipeline.

    (I like buildkite, some like jenkins, etc)

    Use proper branching and code reviews.

    Feature > develop > staging > production

    Every commit on any branch, run some automated tests such as integration, unit tests and code coverage, as well as any additional tools like retirejs

    If you have front end and cant automate it, i advise making a manual block/unblock step from develop to staging for someone who ISN'T the requester to review and test.

    Use PRs to go from each branch and just dont let anyone commit to your staging or production branch without making a PR.

    Branching from staging as a hotfix is acceptable but you should never be branching and PRing into your production branch unless its from staging

    Hope this helps.

    I can go into further detail and give pointers(lol) on how to easily setup buildkite with automation of tests etc.
Add Comment