Wow thank you Joshua and Linda for this great share and testimony 🤗
@bgn9000fr6 күн бұрын
Dune about fear : "I must not fear. Fear is the mind-killer. Fear is the little death that brings obliteration. I will face my fear and I will permit it to pass over me and through me." I think fear is a mind killer at organization level.
@steshaw315 күн бұрын
One team I recall, used the names "atomic" unit test and "molecular" unit test
@joeedh16 күн бұрын
This video is ridiculous. They just sat there and said nothing via bland platitudes for half an hour. They clearly either didn't want to or couldn't discuss what actually happened.
@bgn9000fr29 күн бұрын
Look into the distance like a sailor, and move forward step by step like a mountaineer.
@niranjanpaul217623 күн бұрын
Beautiful
@AgilePoll2 ай бұрын
Lots of gems in this session.
@IndustrialLogic2 ай бұрын
Thanks! Be sure to check out the whole series at 9am PDT every Wednesday through July 31. We have some amazing panelists coming up - Esther Derby, Linda Rising, Barton Friedland, and more!
@user-jw2kc8ip5q3 ай бұрын
I don't see how this explains how Trunk Based Development works with CICD. What artifacts are you pushing to the CD pipeline? Are you pushing the trunk after every single commit a dev makes (that passes CI checks) or are you passing the release branches (which are also supported in Trunk Based). These are the questions this video should have answered.
@IndustrialLogic2 ай бұрын
Thanks for your question. This video is a short clip from a longer live event recording you can find here - kzfaq.info/get/bejne/jL2KZsJ9ns21fI0.htmlfeature=shared. But to answer your questions, one of our panelists, Mike Rieser, has responded to it for you: Trunk-based development requires Continuous Integration but is independent of Continuous Delivery or Continuous Deployment. With Trunk-based development, there isn’t a release branch different from the trunk, and there are almost never any other branches. There may be very rare exceptions or branches that are only used to handoff incomplete work between developers (such as mob.sh). With Trunk-based development, the developers push frequently and directly to Trunk (or mainline), they never hold onto changes for very long. They want their commits integrated quickly and often. They will also pull changes from the mainline frequently as well. If the organization is doing Continuous Deployment, then all the commits to the Trunk (or mainline) will go through all the necessary checks and if they pass go immediately into production or whatever the deployed state of that app is. If the organization is doing Continuous Delivery, there will be a decision made and the deployment will be done when it’s been decided. Either way, it’s the code that has been committed directly to the Trunk or mainline that is deployed, and that is the branch (trunk) where development is done.
@user-jw2kc8ip5q2 ай бұрын
@@IndustrialLogic Thanks for the reply! I do understand that Trunk is more concerned with CI (frequent updates of the trunk), but what I don't understand is "what is passed to the CD pipeline in Trunk based development?". What I understand from Continuous Delivery is that every single commit that is pushed to the main branch should be packaged in a uniquely identifiable artifact. The artifact is then passed through a set of acceptance tests. These tests should provide an answer to the question: "Is this artifact ready for production?". It doesn't have to be deployed at that moment, but you need to know if that artifact is in a prod releasable state, which means the codebase is prod releasable. This is Continuous Delivery for me: making sure devs are using CI, and making sure the trunk is always prod releasable through automated tests. The part that confuses me about Trunk based is that there are also release branches... So should we pass every commit in the trunk to the CD pipeline, or just the commits located in release branches? If we pass the artifacts built from every trunk commit to the CD pipeline, what is the point of the release branches? I thought the purpose of the release branches was to group a set of trunk commits and guarantee they work well enough to be considered "releasable". TL;DR: In Continuous Delivery, if every trunk commit is passed to the CD pipeline, what's the point of the release branches? Thanks! EDIT: I just read the official guide of Trunk Based Development: trunkbaseddevelopment.com/branch-for-release/ They say "CD teams do not do release branches". Everything makes sense now! I went over that page multiple times and apparently my brain just chose to ignore that blue section.
@IndustrialLogic2 ай бұрын
@@user-jw2kc8ip5q First let’s talk about idea and then practical. Ideally, for every commit, you want to run any and all tests you have. In practice, unless the build is seconds to a minute long (possible), you won’t have the time to do this unless you then want for each commit to go through. When the team is small, say 2 - 4 committers (people /pairs / ensembles), you won’t have to wait other commits often. As the team grows, both the frequency of commits increases, and the build times tend to grow over time. At some point you’ll realize that the value of having the build system individually verify each commit isn’t worth the cost of waiting for longer build times. This only works if the team has agreed to, and is practicing CI, then it’s probably OK to not build each commit by itself - each committing group is doing that locally. And important mental model: The build server is NOT doing CI/CD. Humans are. The build server is making sure we didn’t mess up. It is keeping us honest, and makes sure that if we do have a regression, it’s caught quickly (well under an hour), so it is easier to fix, and less code gets built on top of that regression. While it is possible to have a regression, in practice it doesn’t happen too often. So the value of waiting for each individual commit is often not worth the cost of waiting. When a regression happens, we’ll use something like git bisect to find it, and fix it. But while that does happen, it is rare. Something to consider is the idealized form of CI / CD versus the practical version, where you consider transaction costs like build time, and you back off of the ideal to the practical. Regarding release branches. You do not need release branches. You can have them. We’ve used them. And so long as they are short-lived, and any fix you make is then merged back to main, it is OK. However, rather than using either feature or release branches, we prefer to use feature toggles. The code is deployed, but not generally accessible to all users. If we have new work behind a feature toggle, then a defect in a release means: * fix the defect in main * make sure the toggles are configured for what is intended to be available * build and push a new version (preferably with 0 down time) To summarize: * At the end of the day, we only care about working code in production that can be reliably updated and re-released at will. * CI / CD are ways of working - human practices and agreements - that can be supports by tooling. * We keep new features behind feature toggles, to remove the need for both feature branches and release branches * We want to work in ways that reduce risk but do not greatly increase development time * The desire to keep development time down is NOT about rapid feature delivery (it supports it), but is about getting and maintaining rapid feedback * If the build is fast enough, we might run each commit individually, that is ideal, but at some point, the commits are likely to happen faster than the transaction costs for the build time - and you back off of the ideal, accept some risk, and make sure that build failures stop development to get the regression fixed. Your head seems to be in the right place. Keep asking “how is this practice helping.” E.g., why do we need release branches when we do CI/CD. We can work in ways that make them unnecessary, we can work in ways that make them add value.
@bgn9000fr3 ай бұрын
And best feedback comes from great questions.
@IndustrialLogic3 ай бұрын
Absolutely agree!
@marc-speaks7 ай бұрын
I don't hear many people thinking in terms of decades.
@DevinRhode28 ай бұрын
Also creates great data for copilot
@bgn9000fr10 ай бұрын
Very interesting share! enabling fast onboarding and dealing with the arrival of new member in the team. To me, Tuckman theory is pretty outdated and here we have another example of how a real team is evolving much faster than those stages.
@bgn9000fr10 ай бұрын
Perfectly makes sense to work this way (most of the time) rather than having ceremonies that are ending up like a meeting. A continuous ensemble working mixing discovery, build and delivery would be great! 👍🤗👏
@bgn9000fr11 ай бұрын
Love that, thank you! The Driver and the navigators interaction is very clear ! And as we have Rugby World Cup here (in France), I learned something about the mechanics of rugby's backward passes that I can as a metaphor here (compared to soccer). The backward passes is to give someone else to decide what to do next as oppose to continue the action of someone else. So the driver is more a translator in service of the mob than who is driving the work.
@jlangr11 ай бұрын
+1. I always use the word "translator" when describing the driver's role. Drivers build an important skill: they listen to directions about what we're trying to accomplish, then translate it into appropriate code. As skills build (in the language or tooling at hand, in the understanding of the system getting changed, in the ability to parse and interpret verbal direction, etc.), the directions become less detailed. Rather than "turn Left here, go 100 ft, turn right, turn left, etc.", an experienced driver can be told "head to Union Station." In a true driver-navigator role (e.g. in a car or airplane), the "navigators" are making the decision about where to end up. The driver is suppose to be listening to specific direction and otherwise focusing on the road.
@benitz8828 Жыл бұрын
"promo sm"
@QualityCoding Жыл бұрын
Ouch, I'd forgotten the connection difficulties I had at the beginning. Skip the first 3 minutes, folks! 😅
@sunnypandye82432 жыл бұрын
but how do you track continuous improvement then?? how do you know your team is better today then it was yesterday
@alexandersoto63863 жыл бұрын
Great advice
@sonjarudelt36804 жыл бұрын
Simply. Great. Thanks a lot
@vince_only_way_is_up5 жыл бұрын
What do you mean don't measure .. how can you improve the team ????
@jadsayegh62835 жыл бұрын
I'm with @Leandro Camargo. I want to improve performance. Not necessarily of my individual team members, but at least of the team as a whole (which is also in a way a measure of my own performance).
@JorgePicco5 жыл бұрын
You can literally see the emerging patterns as the refactoring to simplicity takes place. The best refactoring video!
@Marcosilva00006 жыл бұрын
I'm looking to measure so I can train and plug weaknesses of each member, also my own
@dotnetchris16 жыл бұрын
I started off a little incredulous at the start of this video, but by the end I completely agree with you. Microtests are what unit tests are supposed to be, but people have done them wrong for so long... Just like microservices (done well) was really all SOA is. SOA was just done wrong for so long it gave birth to the concept of microservices.
@mrbigman99998 жыл бұрын
Ahhh, the pit! I last created the Fusion Project in the Pit. They also kicked me out of the pit because my voice was too loud.
@leandroico9 жыл бұрын
I think that having some sort measurement might be something useful in cases where you have a new team and you want to understand how to better fit everyone in the team. One on one talks can also help, but I think one thing doesn't exclude the other.
@JayBazuzi10 жыл бұрын
1/2 a dozen lines of setup + 10 lines of test? Why so long?
@JonKern5 жыл бұрын
That's so you don't scare people away completely ;-)