4 ms·
This take doesn’t make any sense. What is the author suggest as a replacement, hooking your IDE up to prod via FTP and editing PHP files directly on the live se
by sequoia 4y ago
This take doesn’t make any sense. What is the author suggest as a replacement, hooking your IDE up to prod via FTP and editing PHP files directly on the live server? Sure I’ve done this, as a solo developer on smaller projects, but this doesn’t scale even to a team of two or three, and it goes without saying I’m not relying on tests in this scenario and I have basically no ability to roll back.
“CI is frustrating!!” I hear ya, but this article does nothing to clarify a viable alternative.
- martinald 4y agoI think what the author is meaning is the "CI" tests run on your local machine before you can commit to the repo?
- kcb 4y agoI don't understand why the distinction between pre and post commit really matters. You're building your feature on a branch, you can and should commit as early as you can. Personally I want to get my work off of just my hard drive asap. If it breaks it's not biggie. If you're worried about an ugly commit log you can squash. Gitlab even has a great feature where it will run your CI on the post merged result of a MR. It really is the best of all worlds.
- martinald 4y agoI don't either. The author is also missing that CI servers often have much better hardware/networking than the developers laptop. Even if they don't, it's not crunching away running a CPU and IO intensive test suite on their device for minutes. A good example of this are tests which hit the DB hard, if you are in a different location to the test database servers, the latency between the app server and the db can absolutely murder performance. I can sort of see the problem if you are often seeing CI fails, which require tedius 'fix ci, fix CI 2, fix CI final, fix CI final FINAL' commits taking ages to test and see if it works. But really that's a different problem.