I am a very impressionable person. I get LSS (or ) 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. Last Song Syndrome My former colleague, , 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: Terence 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 which was basically: Gitflow Workflow 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 anyway and 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. master develop Fast forward to recent times. We now have five minute builds, still using Gitflow in our main app, but a simplified in our other minor projects: basically skip and just merge straight to once a feature is done. Github Flow develop master 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 , it will automatically push to and deploy it to production. No running tests. No staging. Everyone just works on . COMMIT master 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 work. Think about it. It forces everyone in the team to do a lot of checks before committing: might Triple check your code. Make sure you are not committing anything unrelated (console logs, debuggers, etc.) think about what you are going to commit (no, please don’t use or worse, . Please) REALLY, REALLY git add . git -am "Did something cool" Run ALL the tests. Smoke test everything. It closely resembles , albeit on a riskier and more destructive scale. currently existing CI/CD workflows 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 , it should auto-deploy to for testing. production staging 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.