If you read the internet, you'll soon realise that a large number of software developers don't understand what CI is and why it's important.
It's ...
For further actions, you may consider blocking this person and/or reporting abuse
I completly agree with most but hate the gameification, rating developpers of your company on a leaderboard on such insignificant factors as commit count... yikes.
This is opening the door for really shitty behaviour, like "oh let's create a commit for each letter I type so I will have a better score"
Granted that this is an extreme example but still, also having a pressure of not being commiting enough when maybe you work on a way more complex part of the project that require more research and planning...
Just don't do that, once you give a score, your back to school.
I think it depends on how healthy your team is. My team understands that it's not at all a rating system, it's just a bit of fun and makes people aware of how frequently (or not) that they are integrating their changes.
I am not at all worried about my team doing shitty behaviour because I don't have a shitty team.
I think this is great and hope you can keep it on like that because I somehow agree with @Clement that this might cause some troubles along the way
I know his examples are a bit extreme and that you trust your team a lot, but it's just that society (especially western society) has taught us to be overly competitive over every single thing that even when we can rationalize that it's just a fun game it can cause some fights inside the team
I don't think you have to throw away all the gamification aspect though, just maybe drop the ranking part? or make it more like you're fighting yourself? I think those things could help to prevent anything from getting out of control in the future
I do like the idea of "fighting yourself", might play around with that idea a bit.
TBH the one metric i'm actually looking at is the team score, if the team is improving at integrating changes then it's doing its job.
Maybe that could be another metric, that would make it more collaborative rather than competitive ;)
I love this idea of CI gamification. We need to be careful with peer scoring though... it can have bad unintended consequences (I've been there myself).
I think code reviews are a pain too! With a good retrospective, we can use this pain to guide a team into pair programming. That's how we did it in a previous team (Full story here philippe.bourgau.net/from-zero-to-...).
We also had success spreading TDD and XP practices with regular team Coding Dojos. Without these practices, it's indeed very difficult to achieve true CI and small commits.
Thanks!
How do you handle unfinished features?
Normally I would create a feature branch an merge it as soon as I'm completely done, while doing a lot of pushes to my feature branch on gitlab to prevent data loss in the case my local environment breaks...
Where would I push my unfinished changes while using the "ci way of doing it"?
Except for this question I'm very curious about actually trying these principles ! Seems to be a nice way of working!
Feature flags are a good way of accomplishing this. Has the added advantage that you can try it out in production for real without effecting real users (if you can control them via cookies for instance)
It depends on the feature and does sometimes take some creative thinking and experience, but it's worth the effort.
A recent example in our team is developing a new react component in isolation (e.g not actually integrating on the page per-se) but allowing us to work on it together.
Hmm seems legit for a new feature/replacement...
But what about database migrations/changes...
What if a new feature requires a database change which would break the previous logic? In this case Feature flags are worthless and the only way of handling it would be a second (or even one for every feature) database...
Or do I get it wrong and there is also a nice solution to this?
I've found it is usually possible with some creative coding to keep db changes backward compatible and this is usually a much safer way of working anyway - irrespective of how you work
e.g keep the old field, introduce new field, code feature toggles against using both and then once you're happy with the new one you can safely delete.
Sometimes though, maybe something doesn't fit into small iterative changes. I would contest this is rare but if it does... well take the hit. Acknowledge it isn't great in this case. One pair works on the awful thing that is perhaps on a branch for a week. They have to contest with merging things etc. You get through it and move on.
I totally agree with you, mostly people trying to make the code perfect! from the beginnings, they don't care about delivering valuable business as much as they care about that string value should be extracted to a separate file because it might be used in different place in the future. Thanks Chris, gonna share the article and hopefully it changes their minds :D
I think this is pretty spot on
Thanks Ben! I want to see photos of ci-league running at Dev.To asap ;)
I'm curious: have you had any issues where people commit too often to inflate their ranking? Or do you enforce a squash workflow where a given feature must be squashed down to a single commit?
The ranking is just a bit of fun and not at all serious. I have a healthy happy team who wouldn't do silly things really, we have some honour :)