4 ms·

Letting devs continuously push their shitty commits to master without passing any sort of CI suite is a recipe for constant broken builds and blocking the deplo

Letting devs continuously push their shitty commits to master without passing any sort of CI suite is a recipe for constant broken builds and blocking the deployability from master from it being constantly broken. Master should be always deployable, or better yet, auto-deploy when anything is merged in. That way your devs are forced to write good, CI-passing code in their branches before they're merged into master.

4lejandrito 11y ago
If your devs are creating shitty commits in the first place maybe you are facing a completely different problem, don't you think? We only push to master after rebasing locally which has worked out well for us for several years. Every commit is supposed to be deployable to live and CI friendly, that is, tested. So, by definition, we don't create shitty commits (most of the time :D).
- teen 11y ago
  Maybe your code isn't done yet but you'd like it replicated to github? This model doesn't allow that
  - 4lejandrito 11y ago
    Sometimes, but very rarely, we do create WIP (Work In Progress) branches so we can push the code to the server. But the idea we follow is to integrate with master a fast as possible ideally with several commits per day. I used to be a fan of the git branching model but since I work like this I find it much easier and less error prone. I guess is the way we've found comfortable for all of us. Just choose what works for you!
    - sopooneo 11y ago
      Does this mean all your features are able to be completed in a day?
xlayn 11y ago
>Letting devs continuously push their shitty commits Do you mind explaining/disclosing your position to dev teams? I hope this is not your point of view of a dev in general. Last please keep it constructive, this doesn't address the source of the problem how did you solve it/what you have tried but just rant about your perception (given no reason is provided).
- stevebmark 11y ago
  I am the dev making shitty commits. I've also worked with devs much smarter than me, and they also make some shitty commits. I have no problem explaining this reasoning to them. I wouldn't use the same language I use as an anonymous internet poster. But everyone makes mistakes. Even the best of the star players break the build every now and then. Even the CTO sometimes takes down the whole system by accident. (Always using) feature branches and auto-deploying master are a solution I like. This also allows for easy code reviews. It also encourages a culture of things like good, detailed commit messages (it's easy to push an un-reviewed commit of "fixes" to master). It's also easy to run auto CI tests on these branches. It also allows for gatekeeping if you have a contractor or someone on your team who shouldn't have full commit access.
RyJones 11y ago
We use Gerrit and Jenkins. Any patch gets hit with CI pre-merge.

4lejandrito 11y ago

If your devs are creating shitty commits in the first place maybe you are facing a completely different problem, don't you think? We only push to master after rebasing locally which has worked out well for us for several years. Every commit is supposed to be deployable to live and CI friendly, that is, tested. So, by definition, we don't create shitty commits (most of the time :D).

teen 11y ago
Maybe your code isn't done yet but you'd like it replicated to github? This model doesn't allow that
- 4lejandrito 11y ago
  Sometimes, but very rarely, we do create WIP (Work In Progress) branches so we can push the code to the server. But the idea we follow is to integrate with master a fast as possible ideally with several commits per day. I used to be a fan of the git branching model but since I work like this I find it much easier and less error prone. I guess is the way we've found comfortable for all of us. Just choose what works for you!
  - sopooneo 11y ago
    Does this mean all your features are able to be completed in a day?

xlayn 11y ago

>Letting devs continuously push their shitty commits Do you mind explaining/disclosing your position to dev teams? I hope this is not your point of view of a dev in general. Last please keep it constructive, this doesn't address the source of the problem how did you solve it/what you have tried but just rant about your perception (given no reason is provided).

stevebmark 11y ago
I am the dev making shitty commits. I've also worked with devs much smarter than me, and they also make some shitty commits. I have no problem explaining this reasoning to them. I wouldn't use the same language I use as an anonymous internet poster. But everyone makes mistakes. Even the best of the star players break the build every now and then. Even the CTO sometimes takes down the whole system by accident. (Always using) feature branches and auto-deploying master are a solution I like. This also allows for easy code reviews. It also encourages a culture of things like good, detailed commit messages (it's easy to push an un-reviewed commit of "fixes" to master). It's also easy to run auto CI tests on these branches. It also allows for gatekeeping if you have a contractor or someone on your team who shouldn't have full commit access.

RyJones 11y ago

We use Gerrit and Jenkins. Any patch gets hit with CI pre-merge.