More on git workflow! I love to think about this issue for some reason, so I’m always willing to discuss my thoughts about it with others, to understand their needs and refine my own processes/thinking.
Eventually I'll get comments or something running so the 0 people who read my blog can join me talking to myself. ;)
I've encountered developers using a workflow where Pull Requests spawn their own environment (on Pantheon) so that in the course of doing code review, they can test that feature in isolation on it's own environment. This didn't make sense to me as I can see many drawbacks.
- Not all hosting platforms allow you to just freely spin up extra envs on a whim.
- If you can spin up extra envs on a whim, how many, and now you need extra tooling to spin em up and tear em down.
- This has to happen, potentially on a high velocity and complexity team/project.
- Seems to introduce friction.
- It seems unnecessary.
What I don’t get about the PR -> env workflow is why you need to test every PR in it's own env before you merge it into a test environment anyway? I feel like this is an invention to compensate for the inadequacies of Gitflow.
The parallel workflow I tried explaining a while back, would eliminate that need. (I’m working on communicating it better.)
Quick recap:
You have 3 environments running code from 3 "parallel" branches of code.
develop- for internal QA and integration testingstage- for UAT/Client Sign offmaster- Always clean, live production code
I suspect part of it comes from a reluctance to merge something bad into develop because people branch new features from there.
That worry goes away once you stop branching features from develop or merging develop into other environments. You stop contaminating everything. The purpose of develop IS to test features the way you use PR envs, except it's integrated, not isolated. You can trash develop at any time, cut a clean one from master and merge the next things you want to test. But you don't usually have to do that often.
Another factor might be not wanting to wait for CI to build/deploy to develop in order to test after merging a PR.
The best answer I have for that right now is "separation of concerns"/ "personal workflow". Code review is a developer task. QA testing is a tester task. Of course we're often wearing both of those hats, but we don't have to wear them both at the same time.
If we have a list of PRs to code review, time box for code review and keep your mind in code mode. Look at the quality of the code. Think about its overall integration and impact with other aspects of the application. Approve or deny the PR and move to the next one.
Once code review is done you can stretch, switch hats, navigate to the develop environment and QA test all those tickets. Or alert someone that they've all been deployed to develop and are ready for testing.
If a feature is rejected at either code review, or develop testing, the developer simply fixes the feature and repeats. You don't have to worry about the state of the develop code (unless its really, REALLY borked) because it's NEVER going anywhere.
This separates the workflow so if we DID have someone else to do testing, it would never have to resemble a dev task with them trying to find the right environment, or think about what's deployed where. Integration/dev QA testing is all done in one place. And you'll have a better chance of discovering early, if one PR negatively affected another. Something you're not going to see testing PRs in isolation.
This gives us economy in our workflow and reduces the mental drain of context switching from analysing code, to navigating environments to testing features, then back again, on a per PR basis.
If you only have one PR to review and test and don't want to wait for a merge deploy... why are you complaining? You're not that busy, and a robot is doing some heavy lifting for you. :p
I'm joking, but in the context of one PR, waiting 5 min for a deploy to happen isn't a lot of overhead. Testing on develop can now happen any time in the future, rather than being bound by availability of extra environments and the velocity of development.
You could spend the time:
- updating the ticket status
- preparing the feature branch for deploy to stage
- Switch to another project and come back to testing things later
- stand up and stretch... It's good for you! :D
You also don't have to review PRs the second they're created. You can do it once or twice a day when they've had a chance to accumulate.
Anyway, Parallel Principle eliminates practically all the risk of bad code reaching higher environments (not accounting for human error), and you only ever need 3 environments:
- Various types of developer internal QA testing: develop
- Client/product owner review/signoff: stage
- Production: master (Always so fresh and so clean!)
*Occasionally an additional environment (epic) if you really need to work on multiple features that depend on each other simultaneously, and then send through the regular test environments together. But that’s usually an exception, not the norm.