Re:A Developer Culture Test
by l0b0 on Tuesday May 26, 2020 @12:02AM
(#23307294)
The original Joel Test was 12 binary and mostly answerable questions, rather than an invitation to BS candidates. This test might be salvageable by cutting it down to the hard questions underneath. For example, "Do you have CI process setup that runs before committing the code?" is one of the best questions here, but rather than "before committing" it should probably read "before deploying to production". I don't think I've ever heard of a local CI process, which is what you would have to do to run it before even committing the code (or maybe the author meant a pre-commit hook?). I would suggest something with little wriggle-room like "Do you run every change through an automated QA process before being able to deploy it to production?" That is, nothing ever gets to production unless the automated (and ideally extensive) process succeeds.
[ Parent
| on HN ]
I guess the word "culture" in the name of the test should have been a warning sign for upcoming vague borderline BS-bingo.
The main point of running a CI process is to stop you breaking the build, so you need it to run before the point where your first build happens. For most teams that will be on a merge to develop, because develop is deployed to a test or QA server. It'd be odd to run CI locally but you definitely want it to happen a long time before anything is ready to go to production.
> It'd be odd to run CI locally
Oh, I would if I could. Conceptually, not very different from running make and fixing any compiler warnings or failed tests before making a commit.
I think that's how a lot of CI gets started: locally runnable tests are automated to make sure they're always run before the commit lands.
Unfortunately automating CI often pulls a lot of server side infrastructure and platform specific mechanisms that break the ability to run it locally. I find it very frustrating to commit, push, wait for server to nag me, fix, commit again, push again, hope it works this time. It just creates a lot of noise and IMO doesn't flow very well. I'd prefer to be able to test everything locally as far as is possible.
One of the nice things about the project I work on is that things like eslint, stylelint, and the unit tests all work locally inside of Docker, so I can be sure I'm pushing code to the repo that won't be rejected by CI for code hygiene reasons. CI runs all that stuff as a check, but it's really there for the integration and end-to-end tests, and the build and deployment processes. If you can get your project to work that way it's really nice to have.
Re:A Developer Culture Test
by ryanbrunner on Tuesday May 26, 2020 @08:03AM
(#23310041)
Sure, but the overwhelming majority of dev teams will run CI on remote branches. That's well after "commit". I think a pre-commit requirement for tests pass would be a turn off for me (I routinely rely on CI to tell me what's wrong with my code so long as it's on a private branch, so I can move onto something else while tests run).