Interview with Abel Wang and Steven St. Jean (Source Control)

Play Interview with Abel Wang and Steven St. Jean (Source Control)
Sign in to queue

The Discussion

  • User profile image
    jfattic

    Great stuff, guys!

    I'd love to see easy reports that measure the maturity of a customer's practices here. It's really hard for a team to get better without more insight into what's going on and what metrics to work toward. Maybe things like:

    # of commits between merges

    time between merges

    how can we measure pending changes that just sit out there for days / weeks and then get rushed into a branch with massive changes and little testing?

    branch depth

    # of active branches

    commit size

    story points (or hours) associated with a commit (another indication of size / impact)

    I'm sure there are better ideas for reports, but it never surprises me to see teams languish in bad practices when they have no insight into what to work toward and what their current practices are costing them.

  • User profile image
    Donovan

    @jfattic: Hey Jeff!  That is great feedback. I will see how we can act on it.

  • User profile image
    Ian Ceicys

    Awesome to see the team back together. You guys rock! Keep up the great stuff.

  • User profile image
    marvinpjr
    GREAT explanations. I watched this all the way through twice and plan to watch again. So, now I have questions, and sorry for the verbosity. :)

    Let's say I'm on an "Agile" team of 3 devs working on a large, monolithic web app. 2 week sprints for development. Using Git. But QA is still manual so longer QA cycle. Don't have much unit test coverage. Trying to follow the strategy that Abel described. Sprint begins, each dev starts a user story. Let's say two of those devs are going to be in the same part of the code.

    If I understood correctly, they are each going to branch off main and create their own PBI/topic/userstory branch locally. None of them is going to put in a pull request to merge back to main until their code is done and they are confident of its quality and stability. I'm thinking maybe the 2 devs working in the same code might be pushing their pbi branches up to remote in order to sync with each other frequently to minimize merge conflicts. Tell me if I have any of that wrong.

    Here's where I'm confused. When a dev is done, I would think that, in the absence of unit tests, part of their confidence that the code is ready for a pull request to main would come from having done a build/deploy to a DEV/integration environment and some manual dev smoke testing there first. Cause "works on my machine", ya know, doesn't always work elsewhere. But if the build + pipeline only runs off main, then am I merging back to main from my PBI branches in order to get it to dev?

    If I am, what happens when dev 1's code gets to dev/int and it's ready to move forward but dev 2's code gets there and there's an issue discovered? Am I gonna hold up dev 1's code from going further until dev 2's code gets stabilized since we're both in main now? How do I not end up cherry picking in that situation? Is this where feature flagging comes in? Would you do that even down at the user story level?

    Marvin

Add Your 2 Cents