I am a very impressionable person. I get LSS (or Last Song Syndrome) a LOT. I usually also get to copy a lot of my colleagues’ catch-phrases especially when they say it every day. It might just be me, or it might be a common occurrence in teams, but so far, I have only see it manifest in myself — but I digress.
My former colleague, Terence, used the word YOLO in almost all his sentences before. It was a no-brainer that I eventually assimilated it and now I am still saying it. For the sane and uninitiated, it was an overused meme before for things like this:
This is my favorite YOLO gif. It’s just perfect.
Okay. So what does YOLO have to do with anything serious like development or deployment?
It started out as a joke in our team: we were in the verge of releasing something and the tests for master were failing. This was back when we had a twenty minute test suite which had a LOT of acceptance tests that were flaky. And flaky they were: it would sometimes fail thrice in a row with different unrelated errors and then pass the next run. This led to frustration and obviously, less deployments per day.
It was one Friday afternoon and we all wanted to go home but we needed to deploy a feature. We were using the Gitflow Workflow which was basically:
- Create feature branch from develop
- Work on feature and finish it
- Merge into develop
- Test in staging
- Merge develop into master
- Deploy to production
- ???
- PROFIT!
So, back to the future, I mean feature. We wanted to deploy it, but master kept failing with flaky tests. I suggested that we just ‘YOLO’ it and deploy. It was already merged into master anyway and develop had already passed, which was basically the same code anyway. We all laughed, but we all knew it was true. So we deployed it. Nothing bad happened that day.
Fast forward to recent times. We now have five minute builds, still using Gitflow in our main app, but a simplified Github Flow in our other minor projects: basically skip develop and just merge straight to master once a feature is done.
One morning, we were just randomly talking when someone mentioned we should do a gem or something that was named ‘YOLO’ because I kept saying it too often. Again, I am very impressionable and the YOLO term hasn’t left my body yet. It just rolls in the tongue so nicely!
I then just blurted out: “What about YOLO Driven Development?”. And off we went into just thinking about how it works.
YOLO Driven Development
So sticking to the YOLO principle, it should be based on something reckless but (probably) has great rewards. I mean, it would be bad if you just YOLO’d and you didn’t have any sort of reward, right?
So here are our thoughts on it:
Setup all environments so when someone makes a COMMIT, it will automatically push to master and deploy it to production. No running tests. No staging. Everyone just works on master.
WHAT? Okay that’s just dumb. I’m out.
Wait! Hear us out! Okay. Are you still there? Hope so. Hear us out. Good. Relax.
It DOES sound like a stupid idea, but it just might work. Think about it. It forces everyone in the team to do a lot of checks before committing:
- Triple check your code.
- Make sure you are not committing anything unrelated (console logs, debuggers, etc.)
- REALLY, REALLY think about what you are going to commit (no, please don’t use
git add .or worse,git -am "Did something cool". Please) - Run ALL the tests.
- Smoke test everything.
It closely resembles currently existing CI/CD workflows, albeit on a riskier and more destructive scale.
Still with me? Now this can REALLY smash something so I don’t suggest just going out there and letting your boss know about the newest fad of deploying stuff. I do think it might be useful in small projects or maybe a modified version can be, instead of auto deploying to production, it should auto-deploy to staging for testing.
Rather tempting isn’t it?
What say you?
Disclaimer: We have not used this in any production workflow and this post has been intended to talk about a joke which could potentially be a good thing. You know, like DOGECoin.