4 ms·

I find it strange that senior developers would laugh at the idea of using quality control gates in a CI/CD pipeline. I know a lot of people don't bother with th

I find it strange that senior developers would laugh at the idea of using quality control gates in a CI/CD pipeline. I know a lot of people don't bother with these things, but most seniors I've worked with would at least aspire to (or say they aspire to) using such techniques. But I guess that's the difference between a senior who knows lots of syntax, and a senior that that knows how to deliver quality.

cryptica 7y ago
I've worked for many companies that had fully automated CI/CD pipelines. If you have a good team which cares about the project, then you don't really need them IMO. The reality of most big corporations is that nobody actually cares about the company. Executives can't trust their engineers to run the tests manually and deliver something that works. If you have a good hiring and promotion process and a fair compensation structure (which none of the big corporations have), then you can trust your employees and so you don't need to micromanage them with automated CI/CD pipelines. In addition, if people actually care, you get much higher quality, more succinct code. No amount of automated checking can lead to improved code quality. It only ensures that the absolute minimum operational requirements are met at any given time.
- blauditore 7y ago
  > If you have a good team which cares about the project, then you don't really need them IMO. I strongly disagree. It's not about caring or not, it's about making mistakes. A human can easily forget to run some test, or generally one step out of many in a complicated procedure, especially if they're new to the project. A reviewer can miss a mis-formed identifier. The more is that automated, the fewer manual steps need to be remembered, and the more safety the project gets. Automated tools like CI/CD should not be considered supervisors to humans, but helpers and safety nets. That being said, there are certainly cases where teams don't set such tools up because they come with an implementation cost. And depending on project complexity and their use case in general, it may be more economical to do things manually.
  - HelloNurse 7y ago
    Not using automatic tools means using a person to do a computer's job. Programmers should work on interesting tasks: refine and revise the tool rules, add even more automatic checks, refactor and correct genuinely flagged code. Refusing automatic check tools means lowering happiness, dignity and productivity, wasting attention and time with bad activities and priorities: following boring and error-prone procedures, finding ways to elude rules and take shortcuts, low-value and tedious detailed code reviews (e.g. discussing indentation instead of incorrect edge cases).
- blowski 7y ago
  You're right that if your team is filled with people that either don't know or don't care about quality, then no amount of automation is going to help. If corporate thinks an automated CI/CD managed by a separate operations team is going to bring quality, then, yeah that's always going to fail. But that doesn't mean all and any automated CI/CD pipeline is not going to help. I've both worked with and implemented CI/CD pipelines, as in a Jenkins script that builds a number of build artefacts and then promotes them to run in a particular environment. As part of the build process, it runs automated tests and static analysis on things like type checking, code style. What it doesn't do is tell us which tests we forgot to write so there's no 100% cast iron guarantee that everything is correct, and I think that's what you're referring to as "improved code quality". But by having that automated step, our human QAs can spend their time on manual exploratory testing (which humans are very good at) rather than manual regression testing (which is extremely slow and inefficient). And our devs can focus code reviews on questions like "is this code clear to me?" rather than "did you meet the in-house code style?" or "have you forgotten about potential nulls?". And we can bring in contractors (who might not care so much) or juniors with a fast onboarding time, since a lot of mistakes will get picked up automatically. If you're working in a sufficiently large organisation, one where independent auditors look at development processes, then you must have a CI/CD pipeline - either a slow, manual one or a fast, automated one. I know which one I'd prefer.
  - eru 7y ago
    > What it doesn't do is tell us which tests we forgot to write [...] There are actually techniques available that help with that.
- watwut 7y ago
  > If you have a good team which cares about the project, then you don't really need them IMO. Of course as senior I do want them if I care about project. It makes it less likely for me to forget. It eliminates one of the "procedural chores" that I have to remember to type on command line. I care about the project and therefore I do not assume that I am unfailing perfection of never making mistake or never skipping a step.
  - eru 7y ago
    Yes, there's only so much attention a human can pay to little details. Unburden the brain, so you can worry about subtle interactions in your code, instead of catching every last trailing space.
- rooam-dev 7y ago
  "No amount of automated checking can lead to improved code quality." - Very untrue. The more automated checks (customized to your needs), the less distraction for devs and more focus on things that matter, e.g. quality.
davedx 7y ago
Senior here, 20 years experience, started out with C++ projects where the only quality gate was the build server failing and currently working on a project where commits fail because of lint rules including things like imports being alphabetized. IME the best approach is a "balanced" one. Let devs push their branches from local to the repo without passing tests or lint rules. (e.g. git push --no-verify). Try and keep your tests fast so devs want to run them locally. (Carrot, not stick). But prevent a merge request from being merged to your trunk branch until everything is green. Personally I find "linters" horrible. They're like someone with OCD leaning over your shoulder while you code. I think VS Code actually runs a LOT slower when the linter is integrated, which can do more harm than good. How crazy is it that TypeScript can do all its advanced type checking faster than the linter?
- eru 7y ago
  > But prevent a merge request from being merged to your trunk branch until everything is green. You want to go even further: only merge feature branches were you know that they won't break master after the merge. Some feature branches might pass tests by themselves, but something has changed with master since they were branched off. Bors (https://bors.tech/ https://bors.tech/) helps with that.
  - davedx 7y ago
    Yep, forcing MR's to be rebased to the last master/develop commit helps a lot here. IIRC this is a feature you can enable in Gitlab. Much less chance your MR will break master/develop if your work is rebased on the latest commit.
    - eru 7y ago
      Bors doesn't force you to rebase. Forcing the rebase is super annoying in projects with more than a few developers (I've worked on one that did). What bors does is essentially the same thing, but automated: after all the tests have run on your MR branch, and people have approved your changes, bors does a speculative merge into master, and runs the tests on that merge commit. If the tests pass, bors declares that very same commit to be the new master. The effect is the same as the Gitlab option you mention, but the busy work is done by the bot.

cryptica 7y ago

I've worked for many companies that had fully automated CI/CD pipelines. If you have a good team which cares about the project, then you don't really need them IMO. The reality of most big corporations is that nobody actually cares about the company. Executives can't trust their engineers to run the tests manually and deliver something that works. If you have a good hiring and promotion process and a fair compensation structure (which none of the big corporations have), then you can trust your employees and so you don't need to micromanage them with automated CI/CD pipelines. In addition, if people actually care, you get much higher quality, more succinct code. No amount of automated checking can lead to improved code quality. It only ensures that the absolute minimum operational requirements are met at any given time.

blauditore 7y ago
> If you have a good team which cares about the project, then you don't really need them IMO. I strongly disagree. It's not about caring or not, it's about making mistakes. A human can easily forget to run some test, or generally one step out of many in a complicated procedure, especially if they're new to the project. A reviewer can miss a mis-formed identifier. The more is that automated, the fewer manual steps need to be remembered, and the more safety the project gets. Automated tools like CI/CD should not be considered supervisors to humans, but helpers and safety nets. That being said, there are certainly cases where teams don't set such tools up because they come with an implementation cost. And depending on project complexity and their use case in general, it may be more economical to do things manually.
- HelloNurse 7y ago
  Not using automatic tools means using a person to do a computer's job. Programmers should work on interesting tasks: refine and revise the tool rules, add even more automatic checks, refactor and correct genuinely flagged code. Refusing automatic check tools means lowering happiness, dignity and productivity, wasting attention and time with bad activities and priorities: following boring and error-prone procedures, finding ways to elude rules and take shortcuts, low-value and tedious detailed code reviews (e.g. discussing indentation instead of incorrect edge cases).
blowski 7y ago
You're right that if your team is filled with people that either don't know or don't care about quality, then no amount of automation is going to help. If corporate thinks an automated CI/CD managed by a separate operations team is going to bring quality, then, yeah that's always going to fail. But that doesn't mean all and any automated CI/CD pipeline is not going to help. I've both worked with and implemented CI/CD pipelines, as in a Jenkins script that builds a number of build artefacts and then promotes them to run in a particular environment. As part of the build process, it runs automated tests and static analysis on things like type checking, code style. What it doesn't do is tell us which tests we forgot to write so there's no 100% cast iron guarantee that everything is correct, and I think that's what you're referring to as "improved code quality". But by having that automated step, our human QAs can spend their time on manual exploratory testing (which humans are very good at) rather than manual regression testing (which is extremely slow and inefficient). And our devs can focus code reviews on questions like "is this code clear to me?" rather than "did you meet the in-house code style?" or "have you forgotten about potential nulls?". And we can bring in contractors (who might not care so much) or juniors with a fast onboarding time, since a lot of mistakes will get picked up automatically. If you're working in a sufficiently large organisation, one where independent auditors look at development processes, then you must have a CI/CD pipeline - either a slow, manual one or a fast, automated one. I know which one I'd prefer.
- eru 7y ago
  > What it doesn't do is tell us which tests we forgot to write [...] There are actually techniques available that help with that.
watwut 7y ago
> If you have a good team which cares about the project, then you don't really need them IMO. Of course as senior I do want them if I care about project. It makes it less likely for me to forget. It eliminates one of the "procedural chores" that I have to remember to type on command line. I care about the project and therefore I do not assume that I am unfailing perfection of never making mistake or never skipping a step.
- eru 7y ago
  Yes, there's only so much attention a human can pay to little details. Unburden the brain, so you can worry about subtle interactions in your code, instead of catching every last trailing space.
rooam-dev 7y ago
"No amount of automated checking can lead to improved code quality." - Very untrue. The more automated checks (customized to your needs), the less distraction for devs and more focus on things that matter, e.g. quality.

davedx 7y ago

Senior here, 20 years experience, started out with C++ projects where the only quality gate was the build server failing and currently working on a project where commits fail because of lint rules including things like imports being alphabetized. IME the best approach is a "balanced" one. Let devs push their branches from local to the repo without passing tests or lint rules. (e.g. git push --no-verify). Try and keep your tests fast so devs want to run them locally. (Carrot, not stick). But prevent a merge request from being merged to your trunk branch until everything is green. Personally I find "linters" horrible. They're like someone with OCD leaning over your shoulder while you code. I think VS Code actually runs a LOT slower when the linter is integrated, which can do more harm than good. How crazy is it that TypeScript can do all its advanced type checking faster than the linter?

eru 7y ago
> But prevent a merge request from being merged to your trunk branch until everything is green. You want to go even further: only merge feature branches were you know that they won't break master after the merge. Some feature branches might pass tests by themselves, but something has changed with master since they were branched off. Bors (https://bors.tech/ https://bors.tech/) helps with that.
- davedx 7y ago
  Yep, forcing MR's to be rebased to the last master/develop commit helps a lot here. IIRC this is a feature you can enable in Gitlab. Much less chance your MR will break master/develop if your work is rebased on the latest commit.
  - eru 7y ago
    Bors doesn't force you to rebase. Forcing the rebase is super annoying in projects with more than a few developers (I've worked on one that did). What bors does is essentially the same thing, but automated: after all the tests have run on your MR branch, and people have approved your changes, bors does a speculative merge into master, and runs the tests on that merge commit. If the tests pass, bors declares that very same commit to be the new master. The effect is the same as the Gitlab option you mention, but the busy work is done by the bot.