4 ms·
The point of contention on this is if you are doing something approximating continuous deployment. In that scenario, the tests and build are part of operations,
by gfodor 12y ago
The point of contention on this is if you are doing something approximating continuous deployment. In that scenario, the tests and build are part of operations, since they are prerequisites to being able to ship code. As such, in an emergency scenario, you do not want to be in a situation where time to recovery is impacted by someone committing a hotfix that has improper whitespace, etc. In the best case, you end up spending additional time having to to 'sign off' on the broken build being just due to the linter (which also introduces a real risk in a high stakes scenario, in that you are shipping a red build and now have another place for human error to creep in) or in the worst case, the system blocks deploys until a commit is pushed to undo the whitespace problem.
- andreasklinger 12y ago1) real emergencies should happen very rarely 2) if they do you dont want to wait until the tests pass - so it's outside of that process anyhow 3) the real root problem here is: "emergency deploys need to be fast and adhoc" - not "linting is part of the ci process"
- gfodor 12y agoI'm not sure I agree -- having an alternate process for deployments in emergency scenarios is just asking for all kinds of trouble. It should be a well oiled machine that is consistent. If running the tests is part of the process, it should always be part of the process, otherwise you introduce additional complexity in trying to understand the potential outcomes of the system in unique scenarios. If the tests are slow that they gunk up the works, then the tests need to be fixed and the process changed. (Perhaps a large suite which runs nightly over less critical code, and a tight suite for mission critical code that runs pre-deploy.)