Git Flow Is A Bad Idea

День тому

What is GitFlow and why is it a bad idea if you want to practice Continuous Delivery or Continuous Integration? GitFlow is a feature branching strategy that adds several extra layers of complexity. Git Flow is bad when we need fast feedback and a clear picture of the quality and 'releasability' of our work, so how do we adapt to get that faster feedback and a clearer picture?
In this episode Dave Farley describes GitFlow, Git feature branch-based GitHubFlow and explores the reasons why they aren’t compatible with the software engineering practices of Continuous Delivery, or Continuous Integration, and describes how Bryan Finster got important sources of information on this topic changed to point out their inappropriateness including revising the description of GitFlow on the Atlassian website.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley

КОМЕНТАРІ: 1 400

@charclay 2 роки тому

If someone tells you that there's only one good or best way to properly build software, regardless of the project scope, project type, language used and team make up, be afraid! No one process is flexible enough to meet the demands of every possible implementation. It's almost like a certain channel owner is trying to sell books or a training course on a competing subject.

@ottorask7676 2 роки тому

(CI, CD, and TBD have all been proven to predict (yes, "predict", not "correlate with") higher performance in software organizations, as per DORA and State of DevOps reports. You can learn more in the book Accelerate if this topic interests you. The book overviews the research methods and more.

@zzzzz2903 Рік тому

Indeed. For example, we release every 6 months (used to be 1 year too) a new version. It's a windows desktop application, users have to install/upgrade manually by running setup.exe. Just FYI, such things also still exist. (it's a financial business application with more than 20 ys codebase)

@joshbarghest7058 Рік тому

Imagine being this defensive about the way you do work lol...log off once in awhile buddy, you look petty otherwise

@joshbarghest7058 Рік тому

@@zzzzz2903 we build financial software. One of our products is a Windows desktop application. The teams that build it use CI/CD. They always know what state the executable is in, though they only release on a predetermined schedule. I don't know why you think there's a conflict there

@zzzzz2903 Рік тому

@@joshbarghest7058 "Continuous deployment is a strategy in software development where code changes to an application are released automatically into the production environment." -- So if you release every 6 months, what do you mean with CD? Also, there is no "production environment". There's 600mb setup.exe. Based on our big customers update cycle (which is sometimes years!), they pick the latest setup.exe at that point, and upgrade to that. Again, what is CD here?

@ern0plus4 2 роки тому

You guys ALWAYS forget non-web applications. In case of these genres "continous" only means "as frequent just as possible". In embedded world, the most frequent release cycle can be even a month long. (Or, probably, there will be only 3-4 releases at all.) And we are not allowed to release, hm, not-too-stable stuff (I tried to re-phrase the word "crappy"), because it's not option to wait for the next release for fixing it, because a bug might be dangerous IRL.

@stephanegeorget1715 2 роки тому

I can relate to that - when the software you write controls a 500 horsepower machine and kill 10 people in the blink of an eye…

@ern0plus4 2 роки тому

@@stephanegeorget1715 Even a machine producing bad coffee until the next update is unacceptable, but yes, cars are the best examples.

@barneylaurance1865 2 роки тому

You might only be able to release your embedded software once a month, but can't you still integrate branches within the repository daily?

@karsh001 2 роки тому

@@barneylaurance1865 not always. For a period I worked on projects where we could hurt or kill our testers if we didn't take proper care. so for safety reasons we had an extra branch for test and before we did manual releases to the test branch we actually went through not only automated testing but also code reviews (manual and automated) before releasing. Yet, mistakes happened, though no-one was hurt as long as I worked there.

@barneylaurance1865 2 роки тому

@@karsh001 OK, so you had to delay delivering the code to the testers to do code reviews for safety. I'm still not sure why you have to delay delivering it to your programming colleagues. I guess you work with an emulator or something so you don't injure yourself when you're writing it.

@aldyj4733 2 роки тому

Instead of choosing what git strategy to use, its better to beef up the testing first... Whatever git strategy you use, it will be useless if you don't have proper and robust automated testing

@manit77 2 роки тому

Yes that's a given but you have to choose a version control strategy.

@thaianle4623 2 роки тому

@@andrealaforgia5066 I believe the test suite is the premise for the whole CI thing to work in the very first place. You could blindly (without any test) commit to the trunk but then, when an issue occurs ("is discovered" would be more accurate), there's no way to tell which commit causes it. That takes time to investigate and make people doubt the CI approach. Sooner or later, they will switch to the feature-branch approach make sure issues are well managed/isolated which actually gives a false sense of security. Adopting CI is matter of choice but having a robust test suite is the matter of implementation.

@mikebell184 2 роки тому

Testing using git-flow is much more aligned than having a haphazard trunk based flow approach. Git-flow naturally allows a dev branch to be properly tested during a sprint BEFORE it merges to master (our single source of truth) and BEFORE it gets released. GIT-flow also helps to manage release notes.

@Yolo_Swagins 2 роки тому

Amen to that. Im currently working in company which do all testing by hand. You hawe no idea how many restless nights our tester yes a one tester hawe.

@jeffthejava1 2 роки тому

@@mikebell184 You are using the Horse-and-Buggy argument. "Our horses work just fine. Horses are better than cars because of XYZ." Yes, GIT-flow WAS amazing. It was great for its time. It's time to move on. No more, develop, master, hotfix, whatever.... It's time to have 1 source of truth. Whatever processes these are steps you would do the test/catch bugs before you merge develop into master, do those same exact processes and steps to each individual branch before it makes it into trunk. So that trunk at any moment is releasable. There's no ambiguity on whether trunk is ready or not.

@sb_dunk Рік тому

I work in an environment where Continuous Integration is not feasible. Git Flow works exceptionally well for our team.

@kishanbsh Рік тому

Curious to know about the environment

@sb_dunk Рік тому

@@kishanbsh I don't exactly want to give specifics, but it's pretty highly regulated, meaning that every development needs quite a bit of design and approval from higher ups. We often work on developments that are quite large and can be rejected by senior people at the last minute. Removing integrated code is much harder than just integrating "manually", i.e. git merge, as soon as we get the green light.

@wilyacalima1280 Рік тому

Looks a lot like good old waterfall... There are better ways to work, but not every industry adapts at the same pace. I guess you can't release every day or week but more likely every month or trimester am I right ?

@georgeFulgeanu Рік тому

Not every idea is feasible without changing your mindset. Last minute changes? - Bad. Rejected at the last minute because of senior people? Why weren't they there sooner? - Bad

@meepk633 11 місяців тому

From the description: "What is GitFlow and why is it a bad idea if you want to practice Continuous Delivery or Continuous Integration?"

@RasmusSchultz 2 роки тому

14:20 again with the claim that feature branches aren't being tested in integration with other changes? But it's perfectly possible to have the CI server merge changes from master before building - and notify you if changes can't be automatically merged. And yeah, that means you're not testing the integration with work on other feature branches - but as you said, that's the intention, to give other teams the time to refine their work. I'll keep following and listening, Dave - but there are still two unanswered questions for me with regards to trunk based development. One, how do we avoid wasting everyone's time with half baked code that needs more than a day to set? And two, how do we do code reviews in practice? These two issues compound, in the form of half baked, unreviewed code ending up in production daily. While that may be acceptable in some environments, it's another situation for teams working under legal oversight or with life critical software - are you really certain this is right for everyone? I'm still watching, but still don't feel like the central issues are being addressed. 🙂

@ottorask7676 2 роки тому

Ensemble working and continuous code review are what you're looking for. You cannot inspect quality in, quality has to be built in. As for half-baked code I don't understand what you're talking about, why would anyone commit code that is not complete? You can hide partly developed features and changes behind feature flags for instance, if that's what you mean.

@gurustron 2 роки тому

@@ottorask7676 "why would anyone commit code that is not complete" - because they don't want it to get lost, for example. "behind feature flags for instance" but feature flags beat the purpose of not having branches which is "finding out that my code is wrong as soon as possible" .

@MartinSchonaker 2 роки тому

You think that "one day" is literal? fetch and rebase is the answer.

@thaianle4623 2 роки тому

From my current understanding of the topic, the most important part of the trunk-based approach is to have tests. Not any hollow unit tests but a complete test suite composes of different kind of tests: unit test, integration test, functional test. A test suite that when you see the GREEN, you know that this is production ready. Every single breech on production should be treated seriously to enhance the test suite. So for any commit, either we get a green on the test suite, or we rollback the commit. Then we don't really need to do the code review on every commit, and this could be a review/improvement process even after the code is committed, not a safeguard check point. As long as we treat every kind of breach seriously, code review shouldn't be an issue. As for half-baked code, for every new feature, there will be multiple commits until the feature is usable. Though, as long as those commits are not breaking current system (passing the test) that should be fine. The feature could be hidden until it's complete but we're still be able to test the new feature together with the current system. So at any point of time developing the new feature, we know that the partial feature still works well with current system without enabling it for end user. And you don't have to release every commit to Production on a daily basis. Still, with the CI approach, there might not be a clean cut where we could find a commit with no half-baked feature to release to Prod. That's exactly when the test suite gives us the confidence to release to Production. If everything work in tandem such as this, there shouldn't be any issue applying this approach. Then, it's crucial to make sure everything works in tandem.

@klichukb 2 роки тому

Feature flags and tests that test both “feature on” / “feature off” states. Develop & merge frequently

@MartinPHellwig 2 роки тому

And so it continuous, the more we try to make agile work in real life, the more we discover it is just waterfall in smaller steps.

@ContinuousDelivery 2 роки тому

Not really, some teams practice agile that way, but the best teams that I have seen don't. Even at the detail level the approach is collaborative and iterative. For example, on the teams that I worked on, POs would sit with the devs and would see the software evolve as it was developed, if at any point we had a question about the requirements, or they didn't like the direction we were taking, we'd talk about it. Testers tested the software while it was being developed, not after development was finished. So really not anything like, even a mini, waterfall at all.

@MartinPHellwig 2 роки тому

@@ContinuousDelivery Yes my original comment has been on purpose facetious. However it looks like you are missing the bigger picture here, all the tools that we have in development, CI, CD, unit- testing, agile, XP, V, etc., are not about methodology in principle. They are about automating or at least formalising communication, and responsibilities from the realisation that any work done has dependencies on previous work and all this should be mapped out to a workflow, otherwise you are just hacking around, which is nothing to be ashamed of, just all parties need to be aware of that. The tools we have help with workflow, which tools we use depends on the particular task and its environment at hand. Doing trunk based CI/CD development when you are creating a prototype to confirm viability is wasting resources. Doing gitflow if you don't need to maintain multiple stable releases is also a waste. Doing agile if you have limited access to the project owners (which must include the end user) but are still held accountable to a timeline is a recipe for failure. Not being able to comprehend the overall picture but regardless advocating for a specific methodology is rather naive. I am not saying that you are doing that, but just that I can't observe any evidence that excludes that. Having said al that, I do enjoy watching your videos and on multiple occasions they have given me the inspiration to think more deeply about what I am doing.

@yash1152 Рік тому

what is a waterall?

@________w 2 роки тому

I like branching to isolate changes which "aren't ready" from everyone else's changes. But I also like frequent rebasing, so that everyone else's changes aren't isolated from the branch. ie: the integration is continuous, but unidirectional. And this also encourages one to break changes into the smallest useful unit, as "being done" has a direct incentive: not needing to be the one who deals with that integration. it's very similar to CI, but admits that some changes really do take more than a day, and that merge-commits act as a useful label for grouping related changes together.

@marshalsea000 2 роки тому

Always get latest, deal with the fall out in your branch, squash and rebase on top. Nobody needs to see all the crap commits that went into building the delivery. Next argument will be but I've got loads of individual parts... Your po is doing a crap job of managing the project and breaking things up wrong... Suspect your using jira which teaches baaaad habits.

@________w 2 роки тому

@@marshalsea000 I've got loads of individual parts, and I'll break them into the easiest-to-read commits. Squash the corrections into the original, but don't make me read about a change to the API at exactly the same time as the new method which justifies it. The justification belongs in the same PR as the change, but not in the same commit

@marshalsea000 2 роки тому

@@________w sounds like you're dealing with a monolith.

@________w 2 роки тому

@@marshalsea000 I tend to call any defined interface an "API". made-up example: needing to support a new type of authentication token, so commit 1: add a new "token type" parameter / ensure it is accepted; commit 2: add support for a second token type; each commit can be read in isolation and makes sense on its own, but the first commit is only justified by the presence of the second commit, and the second commit requires the first commit as a prerequisite in order to be a non-breaking change.

@miletacekovic 2 роки тому

But how do you assure that the code in your branch works? You are running all the tests (including Integration and End-to-End tests) on your machine each time you merge or rebase your local branch? How are you sure the code will work on some other machine before you merge your branch into main?

@dimitrisservis365 2 роки тому

I have a question, do you do automatic testing after the merge and before allowing customers to use the software? If yes, during the time of testing, what software is served?

@vitiok78 2 роки тому

What if some of your tests are bad (sh... happens) but a huge logic bug is hidden and was hidden for two months and it is so complex that can't be fixed in a day or even in a month in the current version because all of the latest features were based on the part of code infested by that bug? Users have noticed that bug and you just have to rollback production to one of the previous releases where it can be fixed in minutes. How to deal with this situation without branching? Maybe this CI/CD flow is based on the "Happy path" assumption?

@joshuaswick 2 роки тому

Your comments at 14:42 resonated with me. I've, thus far, stopped short of CI and instead used small frequently merged feature branches, but you've convinced me to try proper CI. Thank you.

@ContinuousDelivery 2 роки тому

I am pleased to be of service, I hope you enjoy it.

@gabrielpfgm 2 роки тому

This week I had the opportunity to start testing trunk based development with my team. Thank you for the valuable information.

@Heart0rHead Рік тому

If you push your commits to master as soon as tests are green where (or when) is the place for code review?

@constantinegeist1854 Місяць тому

YOLO-oriented development

@loucadufault6549 2 роки тому

This would create a chaotic trunk history. Where you would rebase on a feature branch to simplify history, doing so on the common trunk is nearly impossible with a distributed team. It also makes pushing code to the origin more of a headache. I recently had to work in an environment where the machine hosting the local repository was unreliable, and pushing to the central repository was the only way to back up. Using your approach would have meant that I would need to push incomplete versions of my features to the trunk just for a backup (or create a temporary feature backup branch, which seems antithetical). Lastly, your whole framework seems to be heavily reliant on timeline. It might make sense for a one-day feature, but if that feature suddenly grows into a multiple day task, then you have to worry about finishing quickly just so you don't start lagging behind the current truth (whereas with a feature branch I would simply pull master and rebase my feature branch to refresh the lag from the truth I was working with). Eventually you might give in and truly make it a feature branch, then revert your master and pull the latest before reading the new feature branch, if you deem it is out of scope for a single task. This is an arbitrary, self-imposed limitation that almost acts as a punishment to estimation errors (which are prevalent). I think simplicity has its appeals, but ultimately trying to conform to some theoretical goals while ignoring the practicality leads to issues like those I mentioned. Git-flow has issues, but dev teams should use it as an inspiration for a workflow that better suits their needs. To me, focusing on improving testing, beefing up CI and deployment robustness are all more interesting than striving to adhere to some theoretical metrics.

@hungluu902 Рік тому

I think his mentioned approach only works when the team member are evenly competent. Whatever team size it is, if you have a couple of intern devs inside you team, things could go wrong soon. I worked in a project with aroung 50 devs across many countries and competency (some are from short-term outsourcing companies), if we used his approach should have been nightmare too.

@hungluu902 Рік тому

My 2 cent is, frameworks and libraries are mere tools to developers. We use them the way we see fit to get the best out of them in particular use cases. We are their masters, not their slaves

@krivdaa9627 Рік тому

that's not event the worst case scenario! The worst is "Dude, please __unmegre__ / countercommit all you intermediate commits form the common trunk - you feature is getting postponed for some reasons for several month". The second shitpile is "how to review the code?". The feature branches model gets a perfectly good answer on that: reviews are done on pull-requests. ... and if (when) you want to intergrade your code.. just rebase on master - and run tests. When your are ready to to be included in release - rebase feature on release and run all required tests. the guy simply makes HIS work easy at the cost of introducing the hell-on-wheels to the Dev side

@games4us132 Рік тому

@@hungluu902 some fw and libs become outdated soon, so we came up with this rediculous ci workflow. enjoy.

@cocoach80 Рік тому

@@krivdaa9627 you are not getting the point. If you develop the same way you are developing today, yes, it is going to be a mess. In continuous deployment you separate deployment from release, e.g. by branch by abstraction or feature toggling. You have to use different techniques, but you gain a lot. Open up your mind and try. I would never want to go back to feature branch hell, stop the world releases, ...

@krakulandia 2 роки тому

What about a situation where none of the methods seems to work well: You need to make a fundamental architectural change to your code. Maybe some central module in the code requires completely different approach to it. Refactoring would take 10x the time or simply rewriting it. Refactoring can be done in small steps but would be extremely slow in this case. Complete redesign and rewrite would be the much faster way but you would need to touch lots of areas in the whole codebase to make the change and you can't commit the changes before every part of the code has been changed to use the new module. Thus it sounds like a "one man job" while others aren't allowed to touch the code base at all. A tricky situation. Any suggestions for times like that?

@sergeykolesnik1171 2 роки тому

if you are talking about making incompatible changes to the public API along the way, you are better of making a new repo)

@tube4Thabor 2 роки тому

Why are you claiming that refactoring would be extremely slow? Being able to make changes in small completely working steps is ideal. You can quickly integrate each of the changes, and move on to the next one with confidence. If the hold up really the refactoring, or is the hold up a slow release cycle that is throttling your integration to one step every couple weeks? Doing a complete redesign is almost always actually slower. People who claim it is "faster" to do a high risk rewrite are usually just counting the time to write the first draft. The cost of a change isn't just the time to draft the new code, but to test it, and go through all of the debugging cycles to fix the regression issues.

@thatoneuser8600 2 роки тому

@@tube4Thabor so would your commit message be something like "Refactoring _____ WIP" if you couldn't finish a particular refactoring on that day?

@tube4Thabor 2 роки тому

@@thatoneuser8600 The hypothetical we are working under said the refactoring could be done in pieces. So the commit message should state which piece you actually did and why..

@jasoncole7711 2 роки тому

The problem with a massive change in one hit is that it is almost impossible for people to effectively review; the review cycle alone may span weeks, by which time the branch is stale and you probably need to fix conflicts.....and that's when the bugs creep in. Much better to split the change into smaller tasks which the rest of the team can keep up with. It's fair to say that it *is* more work overall, but the end result is more likely to be better quality. I've been there and done it both ways. For me, velocity trumps everything; stale branches are the enemy.

@none_the_less 2 роки тому

So far I have enjoyed reading the comments. This channel has been attracting knowledge people. I wonder if there is a discord channel where people could extend some of the discussions started here.

@ern0plus4 2 роки тому

10:37 Committing to local master then finally push to central master VS using a branch then finally merge to local then push to central master: they are the same, the result (central master) is identical. With GIT, branching is extremly cheap. If I use SVN: I never make a branch. GIT: never think before branching. Inserting some temporary debug logs to code? Make a short-term branch for it! Pass some half-baked-but-working stuff to a colleague for demo? Fork a disposable branch!

@andrealaforgia 2 роки тому

The point is not the final result.

@ern0plus4 2 роки тому

@@andrealaforgia When I say "result" I mean the whole process. Local changes VS private branches is only a "technical difference" (local changes are dangerous, the changes will be stored on the local machine only, not in the central repository)

@researchandbuild1751 2 роки тому

Git is for people with anxiety. Branching is cheap but the mental context and maintaining where you are is not. You are really giving yourself more work in the end, in the name of feeling "safe"

@andreasbaumann6943 2 роки тому

I used Martin Fowlers excellent guide to branching patterns some 20 years ago to set up software development processes using RCS, PRCS and then later SVN. The branching patterns you use follow the kind of software you develop and the way you want to organize your team, so there is no "one solution fits it all" (as so often).

@piotrd.4850 Рік тому

Can you specify book / publication? I know the author but don't know this one.

@Farren246 2 роки тому

Literally this comes a month after I suggest that in replacing our old versioning approach with Git, that we should work off of trunk alone... an idea which was thoroughly shot down in favour of the GitFlow approach. At least we're now only a decade behind the standard, instead of 2 decades behind...

@muratdemirturk2847 2 роки тому

🤣

@justsaying4471 2 роки тому

Just release more often. Soon enough the master branch will be exactly the same as develop. That way you can bypass the entire discussion.

@Songfugel 2 роки тому

Make a fake email account and sneakily spam your workmates emails anonymously with a link of this video until they come around

@dardanbekteshi3177 2 роки тому

😂

@agile2academy 2 роки тому

Gitflow is best when someone needs to make a complex change. But - and this is what Dave leaves out - gitflow requires someone (team tech lead usually) to be aware of what people are doing. That's often left out of the discussion, but it is the most important thing of all.

@user-16419 Рік тому

Hello Dave, thank you for the video. The idea is quite clear, but I'd like to ask a question to clarify one thing. If we have a new application to build and it will take months before an MVP release is ready. And of course we yet have to write any Integration/UI tests before we even can start doing CI/CD. What branching strategy to choose?

@ContinuousDelivery Рік тому

I choose Continuous Integration, sometimes called (Trunk Based Development). The really important thing in this phase is to spot problems as quickly as possible, because in this phase you will make a lot of mistakes as you explore the problem, and your solution. So CI is EVEN MORE VALUABLE at this time.

@MartynPS 2 роки тому

Interesting, any thoughts on how to manage auditing as part of CI? We have get peer and independent review of each feature branch prior to merge, and audit those reviews prior to release (random sample testing etc). We maintain multiple production versions (mostly due to deployments air gapped), so I can't even approach CD, but do see CI as a better concept for developing at a higher cadance.

@WouterSimonsPlus 2 роки тому

If you can get the audit department to accept the CI server and CD pipeline as good enough, you can do trunk based. Pair programming is great for review, but sometimes that's not accepted because it's hard to audit. If you need the source control system to show a log of reviews, then you can use very tiny feature branches. Basically, the branch should be open only very shortly, for a very small change. This way you can still integrate multiple times per day. That's at least how we solve it in an audit heavy world. Also in CD we are including a risk based change approval flow, connected to the service management tools, which sometimes requires an approval before getting deployed to production. The product owner then gets notified via email and has to approve. Risk is determined by types of change and change sizes and such.

@TwoBananasAndMilk 2 роки тому

Thanks for the video. Quick Q: How do you handle Code Reviews? In my experience with after-the-fact reviews teammates tend to forget or get lazy. With feature branches you can add checks to enforce reviews in pull requests. I'm not talking about catching failing builds, but rather knowledge transfer for new devs or mentoring for juniors. Thank you.

@viktorsoroka4510 2 роки тому

Same question.

@arch126 2 роки тому

In short: pair programming and pair chaning on day to day basis, even for the same tasks.

@ApodyktycznyCzlek 2 роки тому

but you're still doing pull requests in this model if I get it right, aren't you?

@arch126 2 роки тому

@@ApodyktycznyCzlek depends, the goal is to remove the need of merge request because when you collaborate with half of the team for given task the merge requests become unnecessary, because almost all the things caught in review would be corrected while pair programing. Of course you won't get there overnight, but when you will start to notice less and less comments in the code review then you can start shifting to only pair programming, without code review (or code review on demand)

@Quenjii 2 роки тому

@@arch126 I find constant pair programming tedious and inefficient and prefer pull requests for their async as they're much more async.

@BBuckB 2 роки тому

Problem is, many companies doesn't use CI/CD. For Pete's sake, many companies doesn't even test their code before committing ("there's no time to write tests", "it will take too much effort/time/assets etc, maybe in the future", they say). So we have to stick with feature branching, merging regularly and praying that no one breaks the master branch. Sadly.

@Chiramisudo Рік тому

There's no time to NOT write tests! Failing to write tests is an extremely selfish act, forcing your technical debt onto the shoulders of your successors. Don't let your name become a curse word because you *will* live on in infamy in the commit logs.

@Zatarra48 Рік тому

This is us and atm I hold that opinion. We are 3 people handling multiple bigger apps. One standalone and atm 3 build out of a in house framework which share 80plus packages and are modular. We built it ourselves and at at planing stage 5 years ago also decided that we cannot afford it. Would you try to convince me here? I am very curious about that especially as the new one of us now writes test for his stuff.

@Meritumas Рік тому

been there... left quickly...

@krivdaa9627 Рік тому

@@Chiramisudo that's an invalid point. have you ever took loan? mortgage? tech debt is a very similar thing. you get what you want now, and pay for it later. and pay more. why you want to pay more? cause you made a deliberate choice: having a thing now is more important, than some extra money in future. so having a tech debt might be a very reasonable thing. But you must control it. Same as extreme monthly payments on all loans will crush your budget

@Chiramisudo Рік тому

@@krivdaa9627 A poor analogy. With a mortgage, it is YOU who is responsible to pay the debt and not your successors. The ONLY justification, in my mind, is when the company will literally go bankrupt and cease to exist in its current form because it failed to deliver a product before running out of funds. Maintainable (readable, testable, etc.) code is THAT important.

@K3rbalSpace 2 роки тому

Thx, great video. If we have tests that take a long time (they are partly time based), I'd prefer to test on a rebased branch (using our cicd system) and then ffwd merge onto master when they pass. That seems at odds with your definition of TBD? But is it? even if that temporary branch only lasts for as long as the tests run and is simply a container for the input to the automated tests?

@andrealaforgia 2 роки тому

Why not activate the feature for testing and run the build on master?

@BryanFinster 2 роки тому

I'd mock the time. You're really looking for about 5 minutes or less for test feedback from CI.

@originuk 11 місяців тому

Thanks for sharing your valuable insights. I think fundamentally, a highly experienced team would have no issues with adopting such practices. When adding lesser experienced engineers to the mix , and a lack of available senior engineers, things can go horribly wrong. If the code requires some refactoring, it's gonna hurt. Would love to see some real-life examples to compliment your insights... That would go a long way. Happy to discuss further.

@EngineeringVignettes 2 роки тому

Gitflow, my old nemesis. I think that I have had more discussions, in my past jobs, on interpreting Gitflow operation as opposed to discussions about Gitflow projects. It's really just a waterfall-based project management tool (in my mind) which makes it a bad tool for CI/CD anyways. Good discussion! Cheers,

@biomorphic 7 місяців тому

Oh boy, you really didn't understand how it works, did you? Otherwise you would know you talk bullshit. GitFlow is great, and it is agile. Feature flags are cancer, and trunk development is something we were doing 25 years ago. And Subversion was perfectly fine with that. Do not speak about stuff you don't know.

@Jheaff1 2 роки тому

If developers work on a local copy of master and push their changes directly to origin/master, at what point does peer code review happen?

@gigas10 2 роки тому

If you need pre-merge code reviews, branch off master and PR to master.

@Jheaff1 2 роки тому

@@gigas10 Dave refers to that as “feature branching” and instructs us not to do that, though

@soppaism 2 роки тому

@@Jheaff1 The branch here is just a technicality though. If you do reviews, they will inevitably cause some additional delay.

@Jheaff1 2 роки тому

@@soppaism Exactly. Is Dave suggesting we don’t do code reviews?

@soppaism 2 роки тому

@@Jheaff1 It compares to situation where changes would be kept in the local copy just a bit longer before pushing to origin. Probably not a big deal if reviews roll smoothly in the team. Can definitely be an issue, if not...

@gryg666 2 роки тому

Thank you for this talk! I got your point on being sure when pushing the code to "master" branch. But what about the "code review" part? Is it removed from the whole software development flow or how it's realised?

@gryg666 2 роки тому

@@andrealaforgia5066 Even for small things (e.g. 1-2 day effort) you want to do the pair programming? How does this works if 2 devs are working on different features? Making pair programming requires to sync them in same time (which can be hard in remote teams), but also focus switching reduces the sprint velocity (e.g. right now, we're trying to do the code reviews daily at 2pm). I'm trying to imagine how this translates to usual day/week of the programmer. Could you write something about this topic?

@BinarySpike 2 роки тому

I agree that Vincent's statement was respectful. I remember reading Jimmy Bogard-the creator of C#'s Automapper-blog about when to not use Automapper. Having the creator's candid input is very insightful and useful to stop bad or smelly practices.

@scottamolinari 2 роки тому

I have to ask, when is the "CI result" supposed to hit the end user/ system? What system is there out there, where the software gets updated many times a day? I don't know one "end user" of software that gets all updates at the moment they are made and deemed safe and deployable. So, if we can agree, there has to be a split out of deployment updates to happen at different, less often times than CI happens, like at a minimum several days, then we can understand Gitflow better and how it can work with CI. This release cycle is where the bundling of the updates that were "CIed" are pushed out to the "users". In gitflow, that is the move from dev to master. So, CI happens in dev. dev is the "current version". Master is the version pushed to end users (and thus behind the current version almost always). So, to me, Gitflow makes perfect sense with CI too, where dev is the CI'ed branch. The other thing I am missing is the "mistakes" that might be made. Sure, the end use of the program is the feedback, but again, you can't afford to have users continuously stopping their business work, to test the changes in production. Usually, you'd have a stage set up, where you'd ask them to test in. Usually it is in sync with the dev branch. Or, there might even be a QA branch. Branches are hiding changes. They are copies. And they can easily be updated to match dev (which is a common practice too). So, I'm not buying this. I think a CI straight into end user systems never happens or rather is a rare animal, thus the premise of the discussion is wrong. I don't get daily updates on my Windows machine. I don't get daily updates of OSS software I use. And, I don't get daily updates of my cell phone's OS. Etc. Etc.

@1oglop1 2 роки тому

IMO branches are not great not once I've been fixing issues caused by people forgetting to update one or the other branch!

@MikkoRantalainen Рік тому

@@1oglop1 Are you using feature branches that depend on other feature branches? The way I understand feature branches is that new features are based on master and feature branch is merged into master as soon as it's considered final code (note that the feature may not be complete but the code that far is considered good enough to take responsibility).

@QmunkE 2 роки тому

If you're not doing pair programming which I know you're a big proponent of, how would you reconcile a "pull request" type workflow without (even small) feature branches?

@uome2k7 2 роки тому

the benefit of pair programming would be the extra eyes to review. Even with that, the team lead is usually responsible for approving the PRs from my experience. Without pair programming, I would expect the team lead to be doing reviews...as well as other members looking over the PRs to help catch things as well.

@matthewlothian5865 2 роки тому

Mature testing and feedback loops. If it builds and passes tests its good, refactoring can still be done in another iteration. This is a cultural thing a team will need to get used to. With this in mind it's crucial to make sure code is easily testable (TDD can help) and maintainable (Loosly coupled, highly cohesive, modules) as iterative refactoring is expected and encouraged. There a many design patterns and principles that can help keep an application refactor ready.

@mischock123 2 роки тому

Yeah i wonder how to review the incoming coming code so repadly.

@davidboeger6766 2 роки тому

This is my biggest problem with the video (or more specifically his videos against branching). If nothing else, feature branches provide a workspace where developers can back up unfinished work or screw around making changes that don't necessarily compile at any given time and such. I think CI purists can go too far encouraging everyone to commit line by line to master. Not every line of code is an immediate improvement to the underlying system without extensive additional work, testing, etc. Nobody's going to commit a multi-year update to a missile guidance system directly to master, even locally. The feature branch is where the feature lives while it's being tested, reviewed, etc. Not every change is a one-line CSS update from 12 to 14 point font on someone's personal web page. I realize he did propose 1 day as the threshold to decide what gets a feature branch, but given that feature branching is so trivial and cheap and offers lots of practical organizational benefits, I just don't see a case for not using feature branches on anything but the least consequential projects. Also, as much as I hate things like hot fixes and different tracks (master, dev, beta, etc.), there are practical reasons why these are sometimes necessary, such as supporting a one-off customer with a security vulnerability stuck on an older version, or regional regulations that effectively demand different versions of the software. That's stuff that CI/CD purists can't really hand-wave away. I think the principles are extremely important and practical, but I get tired of hearing CI/CD evangelists describe every software project like it's a static web page or a small API, when my whole career has been spent on systems that take a full day just to test, review, and merge, all after the changes are considered finished by the developer.

@matthewlothian5865 2 роки тому

@@davidboeger6766 CI as a practice is not for every project, no silver bullets. Without the culture and enabling organisation / architecture it will be difficult. The main goal of CI IMO is to restrict a freedom of delivery in order to simplify and streamline the process. The restricted freedom is this principle "There is only one working version of the software at any time". This makes reasoning about many other parts of delivery much simpler (but maybe not suitable for your org). Everyting is an iteration. CI can be a difficult paradigme shift, similar to waterfall -> scrum, imperative -> functional, monolith -> microservice, branching -> trunk based

@arturk9181 Рік тому

@ContinuousDelivery I love the series but I have a question. What if I am not working on a feature (an increment) but rather I am changing(an update) a piece of code with accompanying database alter statements? Normally I would have a feature branch for that but how do you propose CI/CD handles this?

@ContinuousDelivery Рік тому

You make the change in a way that everything works after each commit. There is a chapter on Continuous Delivery for data in the CD book. There are other data migration strategies that work for different kinds of data. But it isn’t a barrier, works fine.

@RowanGontier 2 роки тому

The "feedback" on minor changes seems as tricky as making a youtube video- how would you use CI for making this very video? Seems that waiting for the video to be ready before releasing it makes sense. The feature flag would be off until the feature is ready enough right? So production changes would have dead code pretty much all the way until the feature flag is on?

@BosonCollider Рік тому

Very strong disagree with not having branches imho. Having to work within the CI workflow is extremely annoying when developing entirely new modules to a repository with few dependencies and that no one actually uses yet. In those cases, you very definitely do want to have a feature branch. For making small changes to an existing module, this is less of an issue.

@dafyddrees2287 2 роки тому

Thankyou so much. It's really useful to have a place I can refer people that mandate gitflow. (I had to revise this comment several times to remove swearing.)

@uome2k7 2 роки тому

Question...are different branching strategies for different stages in the SDLC? Or are people able to do this CI strategy from first commit? I've mostly worked in git flow houses because the maturity of the developers/project managers aren't there to support single branch workflows. I see how from developer standup, this works and is beneficial...but from experience...how do we get teams up to working this way when they are often new to agile, git, or enterprise software development altogether.

@snarkyswede526 2 роки тому

Agreed, if your team is allowed to break the trunk then CI will not work. It can definitely work from the first commit (though I would recommend getting that first commit in quickly as multiple people creating the build scripts/tooling will cause friction).

@gendin Рік тому

I totally agree with you on this topic, thanks for the video. I have a question though. Currently I'm working in a regulated environment (financial institute) where a "4-eyes-principle" is enforced for every change in the repository. This is implemented in a way that it's not allowed to directly push to trunk and one has to work with pull requests where the tool ensures that every pull request has at least one additional approver (4 eyes). Is this a usecase where you would say that the "GitHub flow" (feature branch flow) is the best possible compromise for continuous delivery or can you imagine any "better" options?

@ContinuousDelivery Рік тому

No, I don't think GitFlow is a good choice in this case. I spent a lot of my career working in regulated industries too. My preference is pair programming. I have yet to find any regulatory regime that doesn't count pair programming as "4 eyes". It is a better review than code review, arguably more efficient than working alone, produces higher quality work and doesn't impose any overhead in the flow, caused by the review. I have a video on that topic here: ukposts.info/have/v-deo/mXmlioCnqYKKzJs.html

@gendin Рік тому

@@ContinuousDelivery Thanks for your reply. We actually do pair programming. Maybe not in every team but there are many teams who do pair and even mob. The challenge here is probably the enforcement of the 4-eyes-principle. The regulatory requirement is that the 4-eyes-principle is not only "lived" but that it is documented and comprehensible for every source code change. So here pair programming is now not enough because even if you do pair - someone still has to commit and to push to trunk and there you only have 2-eyes (single plain Git commit). If the organization allows pushing directly to trunk, than it cannot ensure that all the people really follow 4-eyes-principle using e.g. pair programming. That's why we are enforcing pull requests where the SCM system can at least formally "ensure" the 4-eyes-principle. I hope you can understand what I'm trying to say. Am I missing something? Or there is still a way how we can enforce the 4-eyes-principle with plain Git and trunk based development without pull requests?

@Emerald13 2 роки тому

We've used a variation of gitflow when multiple concurrent versions (sometimes major) of the software need to be maintained. Nowadays in those scenarios, when it's really necessary to maintain multiple versions, I suppose I'd recommend multiple CI branches.

@miletacekovic 2 роки тому

@@andrealaforgia5066 It's not. When you have a Product that has several versions used by customers at the same time, you need several CI pipelines. Consider Spring Framework project, it has to maintain versions 5.x.x and 4.x.x (and maybe some more minor versions) and they work on 6.x.x currently. Then certainly have several CI pipelines for every release branch that is alive and one for the mainline. However, when you have a Project or a Product that is served as a Service (i.e. you do not ship your product to multiple customers), and when you maintain just one single version with CI/CD pipeline, then it is different, you need just one CI/CD pipeline.

@miletacekovic 2 роки тому

@@andrealaforgia5066 Under release branch I assume a live legacy branch of a Product where there are still customers using it. If critical bugs or security issues are discovered in such a branch, they need to be fixed. And CI pipeline is needed for such branch to verify that a bug fix or security issue fix does not break anything. So you need a CI pipeline for every live release branch (that still has customers using it). Of course, you can delay branch creation till bug is found in it, and create a branch from tag when the bug is found. But once branch is created to fix a bug, you need CI pipeline attached to it. Verifying if a bug fix did not break anything on developer workstation is little scary for medium to large systems .

@andrealaforgia 2 роки тому

@@miletacekovic >Of course, you can delay branch creation till bug is found in it, and create a branch from tag when the bug is found. But once branch is created to fix a bug, you need CI pipeline attached to it. It's not a CI pipeline, it's a build pipeline. It's different. CI means something specific: Continuous Integration. You don't do Continuous Integration on the releasae branches, you keep them for hotfixes. In general, however, keeping a release branch for every customer, assuming that you have hundreds of customers, is suicidal, a good recipe for disaster. You cannot really expect to have to hotfix a bug on hundreds of branches. You will need to make those customers converge into a new release at some point. >Verifying if a bug fix did not break anything on developer workstation is little scary for medium to large systems . What developer workstation? Who has ever talking about developer workstations? Developers' workstations are temporary workbenchs. CI is about integrating developers' work into a shared mainline multiple times a day. Tests run on the mainline.

@miletacekovic 2 роки тому

@@andrealaforgia OK, you agreed you need build pipeline on the release branch (ok, call it build pipeline, as tens of developers are probably not fixing bugs on a single release branch, sure). But that build pipeline is basically the same as CI pipeline on the mainline, it cannot be different. It has to contain the very same tests as CI pipeline attached to mainline (including unit/integration/e2e/performance/contract/whatever you have), otherwise, we cannot be sure that nothing is broken with a bug fix. Furthermore, this build pipeline has to run on CI infrastructure, not on developer workstation. So everything here is the same as in the CI pipeline in the mainline, except that it runs on a code from the release branch, so at the end of the day, calling it differently is maybe not justified. > You cannot really expect to have to hotfix a bug on hundreds of branches. Sure not hundreds, but dozen of live release branches on a successful product is not uncommon. > Tests run on the mainline. No, tests run everywhere: developer workstations, CI pipeline on mainline and of course on pipelines on every live release branch.

@andrealaforgia 2 роки тому

@@miletacekovic You are not doing continuous integration on the release branch. Therefore you cannot call the build for that release branch a "CI pipeline". You are fixing bugs on that release branch, you are not continuously integrating new development. That bug-fixing activity causes frustration among your developers, rest assured, given that they have to apply the same fixes in multiple places, with all the problems that that practice entails. If you have several bugs, discovered for multiple client's version, you need to multiply that bug-fixing activity for all those branches, increasing frustration and fear of mistakes. The idea that you can keep release branches open indefinitely is not a sustainable model. It doesn't really work anywhere. You will need, at some point, to make your release branch converge into master again or you are doomed to eternal sadness. Stop calling it "CI pipeline". CI happens *ONLY* on the shared mainline of development, nowhere else. You are talking about separate builds that happen on the CI server. It's not a "CI pipeline".

@juliankennedy 2 роки тому

This was well presented. I do, however, notice that anti-gitflow and pro-trunk discussions often give very little treatment to variations in developer quality and experience and how to deal with them humanely. Also, requirements from other departments and customer driven priorites (ie. bugs and pilot features) are seldom linear in nature or time, in contrast to the commit log in git. No amount of software or automation can adequately replace team members actually communicating with each other. So CI/CD, in my view, can never be the silver bullet to solve all dev issues. Process is more important than software. While gitflow has its faults, and has reached its sell-by date, it was a godsend a decade ago when most teams were still battling to understand git itself, let alone how to actually manage code with it. One thing I do completely agree with, though, are the statements about feedback cycle and its importance. But that was true even before the advent of gitflow.

@justusschwabedal5924 Рік тому

The software industry isn't settled at all. Typically 50% of devs have less than 5 years of experience. So I think your point is still head on.

@astronemir Рік тому

I have an issue with trunk based workflow. How to collaborate on more exploratory and larger features with multiple people, while development on main trunk goes on. I would branch from branches, merge commits from other branches, and visualize it all in branches. When it comes time to merge our feature, we can boil it down to a few self contained and more-easily reviewed commits.

@fexofenadinaGenerica Рік тому

Hi, I'm new to software development so forgive me if this is a dumb question. In the case of, let's say, a desktop app, how would continuos integration/ continuos delivery work? It would be necessary to prompt the user to update the app everytime a small change was pushed? This changes would be modified in the users computer automatically? I say this because is common to have apps only prompt you for big updates, like v2.x, v3.x. Besides, the releases with their respective executables are available just for major updates or new releases are created every time a small change is done? Again, this question may make no sense, I'm just trying to understand how the development would work in a simples desktop app, a plugin, etc, having a only a user and a beginner programming perspective.

@ContinuousDelivery Рік тому

Continuous Integration & Continuous Delivery, certainly, Continuous Deployment, not really. Funnily enough, I explain the difference between C. Delivery and C. Deploy in tonight's video, so keep a look out for that. Continuous Integration is about evaluating everyone's changes together after every commit, nothing to do with release, so perfectly applicable to desktop systems. C. Delivery is "working so your SW is always in a releasable state, so also not related to actually deploying. So also applicable. C. Deploy is, after every successful commit, we push changes to production, so clearly you can't push changes to a desktop app.

@fexofenadinaGenerica Рік тому

@@ContinuousDelivery thanks, I'll be looking forward for your new video and I'll also seek out resources to understand this strategies in more depths.

@dmitrym83 2 роки тому

How does manual testing (qa) fit in trunk-based development strategy? Sometimes, manual testing require days. Would you code freeze the development for the period of testing or would you fully avoid manual testing in favor of automatic testing?

@allmhuran 2 роки тому

@@andrealaforgia5066 But UAT is not only about whether the system is bug-free, In an enterprise environment, or a software house that uses focus groups or similar, it's also about whether the users actually find the proposed solution acceptable. That's necessarily a manual task by definition. I have the same question as dmitry. How do you do UAT (where the U means actual users) given this model? Suppose we push changes to origin/master and trigger a release to a UAT enviornment, and then before the UAT is complete, the production environment is lost. From where do you get the code required to return production to the state it was in before the failure?

@JasonStorey 2 роки тому

Hmmm, Normally I watch these videos and nod along as the suggestions/ideas match my own experience or don't seem particularly contentious, but this is the first time in a while you have really given me something to chew on. I had a pretty visceral defensive reaction against this one and I think I have to go and figure out why and revisit my assumptions. Thanks for keeping things interesting :)

@dropbear9785 2 роки тому

I was also nodding along up to the point where 'bad automated testing' was the reason for needing the production branch. We keep one 'main' branch (aka. master, dev) that has passed automated unit and integration tests. We have customer acceptance and regional regulatory compliance requirements that must pass before dumping our changes out the door, however. Maybe that means we can never do CI/CD? It's also not clear to me how you'd easily conduct A-B tests; maybe project fork and parallel project that deploys behind a load balancer? I'm sure we could make things complicated enough to solve any problems. I feel like GitLab Flow is a closer fit for our workflow, but I should probably revisit my opinions and assumptions, too.

@sauliustb 2 роки тому

The way you're describing your process seems awesome, however, it would require a test suite that is reliable, deterministic, and fully local. If you have to wait for a set of tests to run on a Jenkins machine, then you have to wait too long, and figure out who broke the build. since you can't unit test everything(sometimes you need integration tests), how do you solve that hurdle?

@TARJohnson1979 2 роки тому

The answer is: mix and match. Have multiple test suites: one of which is fast and covers as much as possible which can be run before push, and then put slower tests in a CI server like Jenkins. Those tests do involve waiting, and sometimes you do need to figure out who broke the build, but it's much rarer, and a worthwhile tradeoff. Where possible, when you start getting classes of failure in the slow tests, try to find a way to surface them in the fast tests instead. Over time the compromise becomes less of a compromise :)

@matthewlothian5865 2 роки тому

CI encourages fast feedback, unit testing should be able to give you 80%+ confidence that everything is ok. You really shouldn't rely too heavily on integration testing as it's more complex, less reliable, less helpful and too late for things that an IDE or unit test would catch. I like only smoke tests to check basic connectivity e2e. Unit testing to expected consumer and producer contracts is better IMO. Broken contracts is a management rather than development issue.

@defeqel6537 2 роки тому

@@matthewlothian5865 I've seen enough silly changes to (all kinds of) tests made by developers to have learned not to trust tests to reveal issues from other developers

@lazypeon9158 2 роки тому

In my experience, having successful CI is 100% dependent on having a reliable test suite that the team is committed to using and maintaining. If you don't have this yet, I would recommend focusing on your test suite first and CI second.

@ContinuousDelivery 2 роки тому

@@defeqel6537 Whatever approach you pick, if the developers either don't understand it, or don't copy with it, they will break it. I think what you are saying is that if you are working with bad developers, you need to make them better. There is no process or technical fix that will correct this, this is a cultural change. You don't get to build good software with bad developers, so make the developers better, whatever that takes. I am trying to do that by explaining the techniques that the best dev teams use. (P.S. by "bad developer" I mean people who don't do a good job, not "bad people", in my experience it is easy, or at least possible, to help "bad developers" do better).

@renenadorp7700 2 роки тому

Interesting stuff. Just a question though: what if you would like to have multiple versions of the truth and test these separately? Would that be a case for GitFlow approach?

@ContinuousDelivery 2 роки тому

That's fine as long as you don't need to integrate them again afterwards. So GitFlow has no purpose for that either really, you may as well create branches that go nowhere.

@Luis-fh8cv 7 місяців тому

I’m quite late to the party, but I’m really interested in adopting a workflow similar to the one you suggest. I do want to point out that these days GitHub actions usually merge your branch with the target branch prior to running your tests. It does however slow down development to allow for feedback. The most common approach I’ve seen is the creation of PRs and protected branches such that PRs require at least one team members approval. I was wondering if you had any thoughts on that.

@ContinuousDelivery 7 місяців тому

Yes, PRs are problematic, and not the best way to achieve continuous integration for the reasons that you mention. I have several videos on this idea. The two best alternatives are Pair Programming and "Non-blocking code reviews". You can see my thoughts on each of these in these 2 videos: Pair Programming - ukposts.info/have/v-deo/mXmlioCnqYKKzJs.html Non-blocking CRs - ukposts.info/have/v-deo/j52HmWeIqY2puok.html

@MartinGorz 2 роки тому

How do you feel about CI or even CD in open source Projects? How can you organize and achieve it there? What about validated environments like heath related businesses (pharma, hospitals)? Here each released and used version needs to be validated (sometimes even by outside parties). How would CI / CD work here? Would love to hear you input on these!

@miletacekovic 2 роки тому

GitHub actions? Travis CI? Many open source projects have integrated CI, with CI build state badges, some even with Code Coverage, Static Code quality analysis, Static Code security checks, dependency checks... all free for Open Source projects.

@MartinGorz 2 роки тому

@@miletacekovic I know about the software solutions for Automated pipelines. These are tools to help facilitate CI/CD. They are not continuous integration itself. I was not talking about the technical aspect for open source. But usually open source projects get contributions by being forked and then having a pull request accepted. And, if you saw the video, this is not true continuous integration (CI), since it is basically creating feature branches. That is what my question is directed at. How do you organize it with many distributed people. Or even harder in my opinion in validated environments.

@miletacekovic 2 роки тому

@@MartinGorz Simple branches with pull requests are fine in that case, when you objectively cannot organize pair programming and must do pear review. But then pull requests are better merged into main, no need for Master and Develop and all that complexity.

@BryanFinster 2 роки тому

@@MartinGorz To me, CI makes sense for core contributors who aren't operating on forks, not for external contributors.

@JorgeEscobarMX 2 роки тому

Commiting to master, several times and ensuring that each commit is stable sounds easy enough to execute, then making a pull/merge request (squash commits?) to make a single commit on origin/master seems like a reasonable approach. But I'm afraid that this seems viable just for solo developers, after all Git was created with working with many people at the same time. I'm afraid that, the lack of branches will produce a chaotic git log, and probably will make working with many people a nightmare. How do ensure that all people involved in development have a high sense of discipline to keep their changes not just releasable, but stable on every single commit? This doesn't seem like a easy change to make in a large project with many people involved.

@jonnyevason2219 2 роки тому

Try it and see. I've found it really useful and it's the approach the team I work on take. It's just less context switching and messing and we can simply look at the repo to see the latest code.

@dafyddrees2287 2 роки тому

I worked with 30 devs across Singapore, the UK, and the Western US - all sharing the same big codebase. We managed to work together closely and in all of four years we hardly ever needed to use a branch. We all shared the same codebase - with common ownership (i.e. anybody can change anything.) No need to "fear" anything - you just have to learn the XP way of working in a co-ordinated fashion. Branches are no substitute for working closely with other people. Now I know lots of people fear doing that and don't want to face the possibility of it - but it does actually work. My "nightmare" is not being able to get rapid feedback about things on separate branches working together - that totally kills my ability to refactor and simplify things. The code becomes very, very hard to change- and very quickly. Working with my 30 colleagues on a trunk is a lot easier because catching up quickly with changes - and learning to make small commits makes it much easier to refactor complexity away.

@ContinuousDelivery 2 роки тому

💯😎

@Keilnoth 2 роки тому

@@dafyddrees2287 Were you all working behind feature flags? How do you release feature #1 but not feature #2 when you have everything in master? Also how do you hotfix production when production is not in its own branch?

@dafyddrees2287 2 роки тому

@@Keilnoth Feature flags are a bit of a worst case scenario because we don’t want a combinatorial explosion of switches undermining the usefulness of tests on a CI server. The trick is to build things in the order you want to release them and release very often. We did branch for hotfixes - at that point you are maintaining two different versions of the app anyway. We almost never needed a hot fix though - it happened very rarely, like once a year.

@AdiCherryson 2 роки тому

I'm always curious on what projects are you guys working that you have something to publish every day. How would you divide writing a hardware driver for example so there'd be something 'publishable' before it's finished?

@ContinuousDelivery 2 роки тому

There is a technical advantage to working on code that is "always working" it simplifies things and reduces the risk that you will end up with unanticipated problems. The data backs this up fairly significantly, in that if you don't integrate frequently (at least once per day) the data from about 40k projects (State of DevOps reports) says that you produce lower quality software more slowly.

@TheRealInscrutable Рік тому

I know I'm plate to the party but I have a question. Assume a program with a published version last year (1.0). In the mean time we've done CI internally for a year and have several breaking changes (we're working on 2.0) but someone discovers a bug in the product. So we need a hotfix and a release of the software (1.0.1) that has only that one divergence from the code and that fix is incompatible with 2.0. What would your version tree look like? I've worked in places that had three branches, Development, QA, and Master. We never commit to QA until we think we're ready to commit to Master (all the features are contemplate and all our unit and integration tests cases are complete - now we need QA to try to break it in was we had not previously imagined). In those cases, a hotfix is made to Master and it stays there. Only migrating back into Dev if the original bug is still present. In this example you could argue that we are doing CI on the Dev branch and that we're using the others for the paperwork of keeping the released code in a much cleaner repo. From your short presentation I can't see where this hotfix scenario would fit.

@ContinuousDelivery Рік тому

I would never work like that if I had any choice. My preferred approach is to practice Continuous Delivery, which is working so my software is always in a releasable state, and release as frequently as the biz context allows. The strategy that you describe, statistically, produces lower quality software more slowly than the approach that I just described, based on surveys of 10's of thousands of software projects. The approach that I described is how most of the organisations that we think of as leaders in software development organise things. At the end, you say that you are practicing CI on the Dev branch. This is not really CI unless that is the version of the code that you will release, and if it is, what's the point of the QA and Master branches? The whole idea of CI is to test EXACTLY what you will release.

@dafyddrees2287 2 роки тому

In "lean" terms all the superfluous git flow branches are inventory we're holding onto. (Feature branches are pure "muda".)

@edwardcullen1739 2 роки тому

This, so much, this!

@ivanparushev3132 2 роки тому

Hi, I find the reasoning behind pushing small changes into master convincing in terms of safety and integration, however, I don't understand how I can have a Pull Request if I push my changes directly into master. Isn't this too big of a trade off? Maybe its better to create a feature branch even if its just for 2-3 hours, in order to have PRs?

@arpple0239 2 роки тому

pair programming, or yes just create a mini feature branch. the idea of CI is not about no branching at all but about commit (merge) frequently but branching just tend to become long live so we want avoid that

@thatoneuser8600 2 роки тому

TBD allows for a few feature branches, just that they must all be merged into trunk within 24 hours of creation.

@thiagoampj Рік тому

I have a question regarding ci and this very quick push to master. How do you fit pull request review in this approach as there will be very tiny parts of software that might not describe a feature and the overhead of reviewers?

@ContinuousDelivery Рік тому

My preferred approach is to not use PRs, I explain why in this video: ukposts.info/have/v-deo/eYOAh3uggXmqpoE.html

@thiagoampj Рік тому

@@ContinuousDelivery thanks. I will try more pairing within the team but there's a lot of resistance.

@justinbehnke8724 2 роки тому

Great explanation. I looked at GitFlow once and decided I wasn’t ready for that sophistication. Now I see why it’s mutually exclusive to CD. At 10:00 you described your work flow. I’m not sure if it was just for simplicity or if I’m missing the bigger picture here but shouldn’t someone have reviewed your code before you merged it into origin master?

@andrealaforgia 2 роки тому

>shouldn’t someone have reviewed your code before you merged it into origin master? Yep. The guy sitting next to you in a pair or the guys sitting around you in a mob. Or, in today's pandemic terms, "sitting".

@rudoka 2 роки тому

@@andrealaforgia So how does the person "sitting" next to me see the code that I'm writing? I mean I exchange snippets of code through Teams, often even as screenshots, but eventually I still have to share it somewhere so they can take a look at it. That place is usually a separate branch that does not mess with the production code. I see no desire to "pair program" on the branch that is the "correct version" of the code. There's a lot of talk in this channel about "features", but it is very rare for us to have "features" that take less than 1 day to develop, so having CI in this fashion makes no sense.

@hdufort 2 роки тому

The "Waterfall" and "Wheel" development paradigms are constantly trying to sneak into Agile.

@rootuser5027 2 роки тому

No amount of good planning beats out user feedback. Just engineer egos clouding their judgement.

@Venthe 2 роки тому

@Peter Brown and yet it is consistently proven that waterfall does not work as well as even a crappy implementation of agile

@pilotboba 2 роки тому

@Peter Brown Hmm... I'm not sure agile means what you think it means. To me, agile has the same steps as waterfall, however, you design very small features and implement them rather than designing the whole system upfront then coding the whole system.

@maxperekislov3789 2 роки тому

FDD

@SiavashMehrabi 2 роки тому

I've done this to nearly all my projects without knowing about this, simply because it made sense. It's nice to know that I'm not the only one who came up with this idea.

@manit77 2 роки тому

If you're the only one working on a project why would you even need to branch?

@SmallSpoonBrigade 2 роки тому

@@manit77 Stability and not forcing your customers to have to use one specific version. I've had too many software products where one version won't work, but the previous version and next version do. I've also used a bunch of software where they provide free bug fixes for the life of the current major release, but they charge for major updates. It seems rather difficult to do both of those things if you're not branching. I realize that it's fashionable these days to not know the difference between major, minor and bug fix releases, but it is rather important if you can't guarantee that everybody is going to update to a newer version, or you're charging for major updates. Sometimes a major update means that the hardware that worked for the previous version just can't be supported, but you can't/don't want to leave that software unpatched because there's still significant numbers of people using it.

@athiqurrahman8147 2 роки тому

i assume this is just for software development? I work a lot with terraform and k8s manifest. dev and prod branch reflect their own AWS IaC and k8s state. in this case, committing direct to prod will not work, right?

@maxpowers6880 Рік тому

I have some points which in my oppinion supporting the idea of feature-branches and they are mainly about QA: - Code-Review: A pull request from a feature branch to develop or master can very effectively be reviewed. The reviewer does not need to go through all commits that were made in order to create a feature but only the diff which is present at the end - Testing & Review: If you feature lives on a branch, a Tester / Product Owner can review the version on this branch. If bugs are found or things are missing we do not have that "broken" state on the master but we can fix it on the feature-branch. I think this helps towards having a stable state on master which is always releasable.

@alex_chugaev 2 роки тому

Thank you Dave, for highlighting my favorite CD topics. I'm gonna promote them for my team.

@SeanCarrington 2 роки тому

I think more than anything, branches and git-flow are more crucial to the project management side of things, I found that having branches with names that may correspond to a JIRA ticket code for example is very practical and easier to audit for a PM or Team Lead for example. It's always about what is practical for your organisation.

@krivdaa9627 Рік тому

your point is great, but i'll dare to push it even further. feature branches allow you to make pull requests! and THEY are practically crucial for management

@dmitrygusev669 2 роки тому

Are we using GitFlow right if we use its `develop` branch for CI, and the `main`/`master` branch for CD purposes?

@ContinuousDelivery 2 роки тому

No, there is no “using GitFlow right”, it doesn’t work for CI, and that means it doesn’t work for CD either, because you can’t have CD without CI.

@dmitrygusev669 2 роки тому

But if we integrate our feature branches into `develop` often enough, say, daily, and use `master` to effectively tag releases -- why/how is this not CI? Each "green" commit to `develop` triggers deployment to staging -- how's this not CD? Why can we not use `master` as CD for production environment? GitFlow branching model fits perfectly here. From where I stand we can effectively do CI/CD using this strategy, without attaching labels. wonderfurther

@bradappleton9656 2 роки тому

@@dmitrygusev669 I guess the real issue is how much delay is being created by having separate integration branches for DEV versus PROD. If its only a matter of seconds (or even a few minutes) - maybe its still contiunuous delivery -- BUT you still have to ask what benefit are you gaining from those extra minutes? If its just time spent waiting for an additional approval and/or merge+build (without any better assurance of quality) - then is it worth the extra effort+time+branch?

@nameless_bro1 2 роки тому

Help me please to understand the idea properly: First of all if I caught the idea that, then every change is a new CI-build (i.e. v204*) where every build is a new version of a product? And the secondly what I need to do with open-source projects, what’s about Semver (semantic versioning)? Is that way (CI) also correct to use with open-source?

@rafeu2288 2 роки тому

I suppose you would have rather a SemVer (MAJOR.Minor.patch) with: - the patch being incremented by default; - some keyword (in commit message, like the already supported `[skip ci]`) to make it a new Minor version instead; - some mechanism that makes any breaking change up the MAJOR version instead. Those are my two cents as a junior dev, but I haven't tried it yet, so take it with a grain of salt. ^^""

@mikstratok Рік тому

If all the commits are randomly mixed in a sequence for yet incomplete features that might take weeks or months to develop, how are you going to remove experimental features that don't make the cut if they are hundreds of commits spread over thousands of commits? how do you even make sure those removed features don't leave skeletons behind?

@_b0h4z4rd7 Рік тому

It's even worse. What if i have to fix a bug urgently on the current production version, but there are already committed half of next features that doesn't fit into the current version?

@jeremypnet Рік тому

@@_b0h4z4rd7 branch off the version tag to do the bug fix. I have no answer to the problem raised by Mik Wind though.

@jefedt Рік тому

it sounds good in theory, but it's not easy in practice (ie. juniors, unmotivated people, culture issues). I like github flow with a ci/cd spirit. use a branch to write your code, but it's encouraged to merge 'incomplete' features as soon as possible... at least it gives you the right mindset when it works well, and it naturally falls back to traditional github flow when it doesn't!

@subcan Рік тому

my team uses a concept close to github flow. I agree that it is important to be up to date with the primary branch. Would you agree that always keeping your "branch" in sync with the primary branch would also provide continuous feedback? We do all our builds with Jenkins due to complexity of builds (a whole other discussion). Building on command line is not really an option... so if I am committing my code to the primary branch in order to test, then I have to deal with all conflicts each time. Others may be working on their "story" and not have a 100% solution yet.. so the conflict their code added today may be gone tomorrow? I have a hard time understanding how that would be beneficial? Maybe a hybrid CICD would make more sense in some use cases?

@JesseHoffman 2 роки тому

I'm willing to buy into this but there are a few questions. For example Feature branches allow some form of distribution of knowledge and quality control through a Pull Request review. How can we achieve that when we aren't branching, what are alternatives to that team process. Also, how do you support multiple static and/or ephemeral environments in this case, as multiple branches can easily map to these environments.

@andrealaforgia 2 роки тому

>For example Feature branches allow some form of distribution of knowledge and quality control through a Pull Request review. You can achieve a higher level of distribution of knowledge and *real* quality control by having people work together. Pull requests do not normally guarantee quality control. There are fundamentally 2 scenarios with pull requests: 1) a very large PR is created after days of isolated development on a feature branch, containing a lot of files suddenly presented to the reviewer. Having to statically analyse many different files doesn't give an organic view of how a feature is shaping up. A reviewer might either reject the PR or approve with a "LGTM". 2) a series of small PRs are created at the end of each increment of development, which also create a problem for the reviewer, who now needs to mentally keep up with granular PRs coming his/her way, trying to imagine how the feature is shaping up. >How can we achieve that when we aren't branching, what are alternatives to that team process. Adopt pair and mob programming and you'll get continuous code review. >Also, how do you support multiple static and/or ephemeral environments in this case, as multiple branches can easily map to these environments. Adopt feature toggles and activate the features in specific environments for testing.

@comodsuda 2 роки тому

I'm using gitflow in the current project. For some reason (you know, legacy, no tests, etc.), we can't switch to the proposed method (and CI in general) yet, but we're aiming to. And I have to say that gitflow is great comparing to the lack of any process, where everyone was merging something and at the 'release day' features we needed were cherry-picked to production with constant reverts because of bugs. After introducing gitflow (although not perfect) we can finally take a breath. So I agree with everything you said except the title. It's not ALWAYS a bad idea, sometimes it's a step forward.

@BryanFinster 2 роки тому

You'd be surprised how easy it is to shift to TBD from that state. The code has been tested in production. You don't need high test average of the existing system to switch. All you need to do is have good testing for every change going forward. You commit to "we will never push untested code again!" When I've helped development teams in this situation, we've been able to transition their legacy code in weeks.

@comodsuda 2 роки тому

@@BryanFinster I also transformed one of the projects as you said, however, this one is quite unique. It'd sound strange but we just can't test some of the changes automatically and be sure that they'll work as expected, even on testing environments etc. On the other hand - the system handles thousands of requests per second and in the current state releasing changes multiple times per day is quite expensive. All I wanted to say above is that gitflow is not bad. There are many things to improve in my case and this way of working is one of the less important to change I believe.

@BryanFinster 2 роки тому

@@comodsuda what we found was that solving for this required improving many other things that improved the overall ability to deliver. It acts as a constructive constraint to uncover problems we are numb to. I empathize with the legacy issue. There’s quite a bit more involved than “just don’t branch” when you’re dealing with a multi-team 25 million line monolith made up of 2 decades of untested code. We decided to methodically re-architect to improve our ability to deliver. It takes time, but there is payoff for the org and the teams.

@comodsuda 2 роки тому

@@BryanFinster I'm glad you managed to do that with your team. I think we have totally different contexts :)

@BryanFinster 2 роки тому

@@comodsuda Everyone does. It was a bit bigger than a team though. :)

@resphantom 2 роки тому

We mainly use the feature branch and the develop branch for creating features, however we use release for end-to-end testing. Such as load testing and full functional testing, going through all the quality checks. Integration testing, unit testing and vulnerability scanning happens on all branches. But personally I prefer only having a master branch and multiple features.

@DennisKardys 2 роки тому

In the CI model, what's best practice for a team that's working on multiple changes to a website or application, but only some of those changes are approved by business stakeholders to be released (visibly) into production? I am thinking about situations where we may have bug fixes and subsets of new functionality that we want deployed and released, but we also have global CSS, JS, or other shared code that would result in changes to the UI that are not yet finalized or approved to go live?

@ContinuousDelivery 2 роки тому

Ultimately to speed up, or eliminate, the approval process, or hide the change from use in production. One of the philosophies of Continuous Delivery is to work so that "our software is always in a releasable state" that means that every change that we commit needs to be ok to go into production. That means that we may need to change how we work, maybe making changes that aren't yet available for use, even if they are deployed into production. The simplest way to think about this is "Feature Flags" but there are other strategies too. One way to think about this is that CD works backwards starting from reality. The reality is that the "truth" of our system is what ends up in prod. If we want to test that "truth" before we deploy it into prod, we need to be able to generate (and test) EXACTLY the collection of bytes that will end up in prod. If we want to evaluate EXACTLY that collection of bytes, then we must do CI and CI is about evaluating EXACTLY the collection of changes that may at some point end up in prod, together frequently. That means we can't afford to hide changes! That means that we can't afford things that slow us down and segregate changes in the same code base. That means you can't have review cycles that take longer than minutes, certainly not that take more than days.

@allmhuran 2 роки тому

@@ContinuousDelivery The one thing I've never quite grasped is how enterprise UAT is meant to fit into the process given the two assertions, (1) "our software is always in a releasable state" and (2) "changes are pushed directly to master". Suppose Alice changes some code. She does her local unit testing and the unit tests pass. If she's lucky some domain expert end user who is closely associated with the dev team might even look at the result. Suppose this happens and they say it looks good. Alice's code now needs to go through full UAT. A larger group of users will perform a number of well defined tests while they also look over the system, just in case there's something about the new functionality that they hate, or doesn't work they way they expected. Where does this happen? Suppose Alice pushes to master and we trigger the first stage of the release pipeline, which deploys to a UAT environment. At this point the code that is actually in production is not the code at the head of master. Now suppose some kind of DR or business continuity event happens and we lose the production environment. Which code do we deploy to production to bring us back to what was in production immediately prior to the production environment failure? You can't take the head of master, since that's got Alice's as-yet-not-fully-UAT'd changes.

@joegaffney8006 2 роки тому

How would this work with code reviews? Often feature branches offer the benefit of code reviews as well. Was thinking that could possible by making release branches from master/main and reviewing then? * Sorry I mean merging to a release branch so you see all the changes since the last production release together.

@ContinuousDelivery 2 роки тому

My preference is pair programming, so there is no separate "code review" step and so no need for PRs. You get a better code review than code-review alone and lots of other benefits with Pair programming.

@bitti1975 2 роки тому

@@ContinuousDelivery @Andrea Laforgia I'm repeating myself, from above, but it seems it's necessary: Code Reviews and Pair Programming are different things and not interchangeable. Working together with someone on the same code leads to a different perception of the result then for someone with fresh eyes. So even for teams in the same timezone code reviews should be done asynchronously. That is: asynchronous code reviews have a different set of advantages/disadvantages and are not just borne out of necessity. While I think pair programming is highly desirable it doesn't make code reviews expendable.

@andrealaforgia 2 роки тому

@@bitti1975 No one has ever said that, with pair programming, code reviews are expendables. Async code reviews are though. It all depends on what you mean by code reviews. If you mean PRs, yes, they can be removed with pair programming. Code review is a fundamental activity that you make *continuous* with pair programming. You shift left the code vetting, decision, agreements you would normally perform in a PR. The best way to review code is to make decisions whilst working on it, not after. There is a mountain of evidence that proves that pair programming is highly effective, and mob programming is even better.

@joegaffney8006 2 роки тому

@@ContinuousDelivery what to do when pair programming isn't practical from an organisational standpoint. What would you suggest then?

@bitti1975 2 роки тому

@@andrealaforgia I explicitly specified code reviews as an asynchronous activity. So yes, even you seem to think they are expandable. Saying "The best way to review code is to make decisions whilst working on it, not after" is just a postulation, but at least it means you acknowledge that there is a difference. Some things are easily overlooked in the heat of the moment so while it is desirable to improve code as early as possible, some things can only be seen with a certain distance. I don't know why you have to reiterate that there is high value in pair programming though, which I agreed to anyway.

@kaiserbergin 2 роки тому

Push origin master? How do you handle code reviews and ensuring quality? "It works" is a dangerously nebulous term... It compiles? Great. But does it actually _work_? And if it doesn't, what then?

@pappont 2 роки тому

If you use pair programming, there is no code review. And pair programming provides much better feedback than code review

@TV-xd1pb Рік тому

Imagine all work like that without any PR just push origin master in open source project and some popular frameworks...

@JayVal90 2 роки тому

Why not just use Google Docs for your version control? MINIMUM cycle times, MAXIMUM deliveries.

@hicnar Рік тому

Or NFS where everybody car read-write at will :D

@frankseidinger2112 Рік тому

Does working on the local master mean, that I have to have a local build pipeline as well? Or do I risk that my changes do not have the required quality to go into production, break the main build, have to make changes to my local master and push again until my code meets the quality gates?

@ddanielsandberg Рік тому

A pipeline does not replace the steps and tasks in a build script (npm, gulp, gradle, maven, etc). This is a common mistake I see, where teams replaces everything they had in their scripts with a pipeline YAML that can only run on some build management system. When practicing CI you should be able to run the majority of the build steps including unit test, some component and functional testing locally. Whole system acceptance tests is difficult and often too slow to run locally. It also serves as feedback; if it is difficult to run, build, test, lint, you probably need to look into the structure and design of both tests and code. If it is very hard or slow to build/test locally you may need to look into the the technology choices made (like frameworks, etc). It is an optimization technique where you should be able to compile, package and run 10000s of tests locally in minutes. Enough that it gives the developers a high degree of confidence that it will work before pushing. The build management system will of course run the commit build as well, plus a bunch of slow wider system tests, performance, etc. This also has the added benefit that if GitHub is down (like it is now as I write this) you can have a "break glass" process and build an emergency patch on a (monitored) local computer and push that to production. While the build system runs the commit build you are not allowed to go away, lunch, or home. If it breaks you have 10 minutes to fix it or revert the change. If it's still broken the team swarm around the problem and get it back to green.

@cdarrigo 2 роки тому

Dave, what is your thought about short-lived branches for the sole purpose of having a commit set that is subject to pure code review before it's merged into master. That's obviously slows now development process because we've now introduced a manual review. But if safety is paramount, then we want to ensure a code is developed with best practices and adherence to standards, and not just meeting the functional requirements

@ContinuousDelivery 2 роки тому

I think that they are a small form of waste. I prefer to work on master all the time, I can do code reviews as pair programming.

@cdarrigo 2 роки тому

@@ContinuousDelivery I found it takes far longer to peer program something unless there is a difficult problem to solve. I don't know it's a good use of my day to spend watching a junior developer code only to jump in every time I see an opportunity for improvement. She was far better to wait until they're comfortable with what they've written and do a review in a fraction of the time

@clickrush 2 роки тому

"Represents the reality of Software Development" - What reality? Branching isn't complicated or slow and it certainly doesn't prevent continuous feedback. You can always choose to merge other branches into your working (or feature or w/e) branch *at your discretion* . The "reality" is different for each developer, team and organization. Say you have a testing environment that runs in parallel to your production environment so your non-technical stakeholders can provide feedback and are free to experiment themselves. Do you really want to deploy these two different environments from the same branch? If yes, you just made things more *complicated* in the real sense of the word. You are tangling up two things that should be separate and simple. Another reality is that you might have fluent, constant communication in your team and a codebase that allows for separated features, modules and abstractions to be developed independently. You communicate and know in advance that they won't intersect in critical/logical areas, but only in the plumbing. It becomes useful to separate these working items into branches, because merging/coordinating plumbing code is straight forward, but becomes tedious or even inefficient if you need to do it constantly because you don't know yet how to connect the dots before certain parts are finished. So in conclusion, I find this advice useful if modified this way: If you work in small teams, direct communication between developers and other stakeholders is guaranteed, then use the branching strategy that fits your needs AKA "the reality" and don't just follow a predetermined pattern (like git flow) but make it as simple as it can be, but no simpler. Strong conventions and rules can become useful only if you need to context switch between many different teams and projects. Otherwise just use your tools and adapt your processes to your reality.

@clickrush 2 роки тому

@@andrealaforgia5066 processes and tools cannot substitute communication and engagement with your coworkers. There is not one size fits all, no silver bullet is what I'm getting at. The beauty of git is that is doesn't inherently prevent you from merging or branching. If you need to branch, then do it, if you need to merge, then do that. It is a highly dynamic system. Using it should be driven by actual needs, not arbitrary rules. Saying that rule/methodology X simplifies things begs the question: Under what circumstance? Simplification is not subjective. It means you are disentangling something that should not be intertwined. The subjective part is the "reality" that you model and work with.

@andrealaforgia 2 роки тому

@@clickrush >processes and tools cannot substitute communication and engagement with your coworkers. There is not one size fits all, no silver bullet is what I'm getting at. Again, this is a typical logical fallacy, black&white reasoning. Who ever said that CI is a "silver bullet"? CI is a way of working that has proven to be better than other ways of working to develop software. Period. No one has ever stated, in any books/resources/articles about CI, that CI is a "silver bullet". People keep rejecting CI and trunk-based development putting a lot of emphasis on communication, like communication were the only thing a team needs in order to deliver software. A team needs to be able to continuously integrate their work. That's the point. CI is not substituting communication and engagement with your coworkers. How is a long-lived feature branch approach fostering any communication, given that it's a way to hide your changes and silo your development? Developers adopting feature branches often do not communicate for days and days, only to discover problems at the time of merging their changes. >The beauty of git is that is doesn't inherently prevent you from merging or branching. I don't see that as a "beauty". This video is not about git, it's about GitFlow. It's different. >Saying that rule/methodology X simplifies things begs the question: Under what circumstance? How much do you know about CI, which has been going on for almost 2 decades, and all the studies about it that prove it's the best way to develop software we know so far? Read "Accelerate".

@clickrush 2 роки тому

@@andrealaforgia I wasn't arguing against CI generally. I was questioning the notion that one particular way of using git "represents reality" for all, and was giving examples where you make things more complicated if your model doesn't match your circumstances. What may happen if you don't separate work into branches on the VCS level is that you are separating it on the code level. You introduce configuration and (ad-hoc) logic in your code base so you can accommodate staging environments, beta/prototype features and so on. Which means you need to test that code too, which means you blow up your code base just so you can avoid branching. It's a tradeoff. In some cases this is great, in some it isn't. Again, my point is not against CI generally. It is against big claims of how people should use their tools by making statements about "reality" and "best practices". And I didn't want to say this at first because it shouldn't matter, but I don't need to be convinced of simple branching models and CI, I/we actually use CI most of time, probably over 95%, except when we don't. When we need a branch for something then we just branch instead of coming up with a convoluted way of avoiding it.

@andrealaforgia 2 роки тому

@@clickrush >I wasn't arguing against CI generally. I was questioning the notion that one particular way of using git "represents reality" for all I see a contradiction there. CI does dictate "one particular way of using your VCS". The definition of CI is "practice of merging all developers' working copies to a shared mainline several times a day" so if you're not questioning CI, you shouldn't be questioning trunk-based development either, cause CI and TBD are the same thing. Nobody is saying that this particular way of using git represents reality for all. What has been said is that if you want to implement CI, you need to give up ways of working that are antithetical to CI, and GitFlow is one of them for the reasons exposed. You are still free not to do CI, though. >What may happen if you don't separate work into branches on the VCS level is that you are separating it on the code level. You introduce configuration and (ad-hoc) logic in your code base so you can accommodate staging environments, beta/prototype features and so on. Which means you need to test that code too, which means you blow up your code base just so you can avoid branching. Absolutely not. Have you actually ever tried trunk-based development + feature toggles? It's much easier than you'd think. When feature toggles are inactive, you can consider the code they hide as not there at all. Separating the code physically (feature branches) offers less benefits than separating it logically (feature toggles). The latter approach at least makes sure that the various streams of development are integrated, the former doesn't, and the longer those branches live, the more they diverge from each other and master, the riskier it becomes to merge them into master. You can switch features on in your specific test environment and do all you want. It's much cleaner and simpler. The ability to integrate work and the ability to test/release features are two different aspects of software development. Note that you say "you blow up your code base just so you can avoid branching". First, you don't blow up at all your code base, quite the contrary. Second: the purpose here is not to avoid branches, but to fulfil the definition of CI. The fact that branches are avoided is a nice side effect.

@OldWiseLlama 2 роки тому

I think continuous integration is a good idea, but I think pushing directly to origin/main (or origin/master) is a bad idea. My preferred way of working is to split backlog items / user stories into small (mostly) atomic tasks that aim to introduce one small addition. When starting a task we create a task branch, that is short lived. When we are ready to integrate we create a pull request and another member of the team peer-reviews the task. I don't care how senior or seasoned a developer is, nobody pushes directory to main. All developers are human and everyone makes mistakes. By peer-reviewing every single addition to the code base we catch these small mistakes early. When the team works at full speed each developer can still implement multiple tasks in a day all the while reviewing tasks from other developers. The added benefit of this is that you get to read other people's code daily. That is a great way to learn. Maybe someone knows a nifty trick to tackle a certain problem. When you get to read this code then you learn this nifty trick too. Reviewing is not just about finding mistakes it is also a great way to spread knowledge.

@andrealaforgia 2 роки тому

>I think continuous integration is a good idea, but I think pushing directly to origin/main (or origin/master) is a bad idea. That's a contradiction :) It's not CI if you don't push directly to the main branch of development multiple times a day. Note that CI and trunk-based development are the same thing. >My preferred way of working is to split backlog items / user stories into small (mostly) atomic tasks that aim to introduce one small addition. That's great. >All developers are human and everyone makes mistakes. By peer-reviewing every single addition to the code base we catch these small mistakes early. Sure, and that's why CI is not removing the benefit of code reviews from the picture. It's only advocating a different way of reviewing code, through continuous code reviews that happen *while* developing, and not at the end. There are various disadvantages of having PRs at the end of development phases: it's extremely hard for a reviewer that has not been involved in the development of a feature to get a good understanding of what the code does. You haven't seen it working live, you only have a bunch of files to statically analyse. The risk is that reviewers only skim through the files for a superficial validation, trusting the creator of the PR (especially if she/he is a senior member of the team who knows the system well) and coming up with a "LGTM". This is were PRs can become really dangerous tools. It is much better to use pair/mob programming and continuously review the code while working on it. >The added benefit of this is that you get to read other people's code daily. Is that a benefit? Having to stop your development activities to read other people's code of which you know very little? >That is a great way to learn. Sure, but learning through collaboration is 10x better.

@OldWiseLlama 2 роки тому

I has worked well for me to take a break from what I'm doing to look at someone else's work. I gives be am opportunity to step back from what I was doing. It often gives me new ideas or I might realize something that I wouldn't necessarily have though about if I was just doing what I was doing.

@OldWiseLlama 2 роки тому

Also keeping the diff small helps. And you should always checkout the branch you are reviewing and look around the code, not just the diff. You can try building and running it locally while you're at it.

@JuanCarlosPerezAmin Рік тому

I am intestered in a TDB vs CI 🤔 Good or Bad Idea

@c_kemper 2 роки тому

What workflow do you suggest then for infra as code, where you don't have the luxury of spinning up an ephemeral environment to test for every little change you make?

@ContinuousDelivery 2 роки тому

There is a lot to that question. Fundamentally, the principles don't change whatever the deployment target. We want to version control the state of our systems. For on-prem stuff, unless it makes sense to build a private cloud (and it often doesn't) clearly you are going to be working with more fixed hardware/server config, but still I want to version as much as possible on top of that. OS/Web Servers/Database/Messaging/Config of all of these before we even get to the system you are building. By default automate the config of this stuff as far as you can possible get. If you are writing apps that run on other people's systems, you can't version the OS, but take it a far as you can so that you can control the variables. The tech you choose is so varied that it probably makes little sense to specify it, but Docker, Shell Scripts, Chef, Puppet, Ansible are all workable options. In the past I have worked in teams that did Infra as code driven by home grown deployment & config tools coordinated with ANT scripts. Testing this is useful, applying CD techniques to Deployment Pipelines works nicely. Create a very simple test-pipeline, and a simple test environment that you can configure and write some simple acceptance tests to confirm that changes to the pipeline work. There is lots to all of this, but most of my experience of Infra-as-code was in these types of environments.

@BrunoGabrielAraujoLebtag 2 роки тому

Please, make a video about clean code (the book). Personally, I don't like it. Give us your thoughts about it. It would be interesting.

@k3agan 2 роки тому

Personally I liked it, but still would be interested in Dave's thoughts 🤔

@alex_chugaev 2 роки тому

What's wrong with Clean Code?

@EngineeringVignettes 2 роки тому

Are you referring to Robert Martin's books?

@BrunoGabrielAraujoLebtag 2 роки тому

@@EngineeringVignettes Yes

@rajm1976 2 роки тому

I love this book. Not sure why people dislike it. But it is just one book amoung hundreds who think they are right

@ChristopherCricketWallace 2 роки тому

I am SURE that I am misunderstanding something about Continuous Integration as you describe it now... My question is about development on a non-trivial, wide-reaching, breaking change/feature/spec. HOW do you pull in the current changes from other devs while you're actively changing what they are changing. Won't you be repeated your conversions multiple times a day? Do you need to engineer a SHIPPABLE transitional state as you move toward the new, breaking, end-result?

@andrealaforgia 2 роки тому

You don't "pull in" those changes. You and the other devs work on the same codebase (Continuous Integration Trunk-based development). Working on the same codebase and committing micro changesets multiple times a day, you break down work more easily, hiding incomplete features behind feature toggles, and avoid merge hell.

@EngineeringVignettes 2 роки тому

@@andrealaforgia - Yes, unless the Gitflow project is ruled by an "iron fist", it does become a _merge hell_ as more branches are created and changes start to occur on a released product. CI merge change deltas are small so potential merge conflicts are minimal, if any. I think one of the toughest challenges, when moving from waterfall to CI, is in the breaking down of work items into smaller pieces, which requires additional discipline and effort. A single waterfall work item may even be an epic in a CI equivalent... Just my opinion though... Cheers,

@soppaism 2 роки тому

There is an exception to every rule. Major groundwork changes may still need a branch.

@EphraimMower 2 роки тому

Feature Toggles/Flags can isolate changes until they are complete, but teams have to be diligent about maintaining compatibility, using an expand/contract approach, and cleaning toggles up later

@andrealaforgia 2 роки тому

@@soppaism not even needed for that. Major groundwork can and should be done in a TBD way.

@Storytelless 6 місяців тому

I'm trying to understand it right. So imagine we have an app and we want to introduce new big feature there - for example facebook-like feed. It has plenty visual components, forms to create post, post itself, photos preview that should open a photo gallery and comments and video attachment... we sure can do each element separately pushing them directly to production accessible to our users, but is it a good idea to present them a half-baked feature? Or the idea is that in this kind of situation changes stay local until we have feed component ready? But in that case how to split work effectively between the developers?

@shashank.c 2 роки тому

Dave's videos are really a great insight to understand the basics of software engineering. I have a few questions after watching this episode. How do we do peer review when working on master branch directly? I understand that pair programming is an effective way to improve code quality, but does that eliminate the need for peer review? Is peer review an overrated concept?

@ContinuousDelivery 2 роки тому

Yes, it eliminates the need for peer review, because you have a constant “peer review” during construction. I have worked in several different regulated industries, all of which required peer-review, pair programming counted as peer review in all of them. The quality of work produced by pair programming is certainly, measurably, higher than code without pairing. I haven’t seen any academic studies of “pair vs peer review” but subjectively, the places where I worked and did pairing built better software than the places where we did peer review.

@tube4Thabor 2 роки тому

It is better to have the review happing while you are writing than after you think you are done.

@a544jh 2 роки тому

@@ContinuousDelivery The problem is that a lot of developers don't like pair programming.

@ottorask7676 2 роки тому

@@a544jh It is sad that people have been lured into our industry thinking that they don't have to work in a team or interact with people, which is at the core of software development. Ensemble working is the better default approach.

@ContinuousDelivery 2 роки тому

@@a544jh in my experience the problem is that a lot of developers haven't tried it. My experience has been that the majority of devs prefer it once they have tried it, and a small minority, less than 1 in 10, really dislike it.

@quantondev 2 роки тому

Wonderful content. I think the same mostly. But when there is juniors on team sadly it might not be possible to go complete ci since junior dev codes although it is working it might need refactoring and review. And we are trying to do pair programming as well but there are some limitations for that like timezones etc. Outside of this I strongly agree on what you think.

@baTonkaTruck 2 роки тому

I totally agree. Gitflow is antithetical to actual CI. I have tried to change many teams’ process but it never, ever works. People agree what I suggest would be better, but I can’t get around the organizational inertia.

@uome2k7 2 роки тому

Yep. The project manager, business analyst and project owner all have to be on their game to support such a workflow just as much as the development team needs to be.

@rumplstiltztinkerstein 2 роки тому

I started learning CI a few weeks ago to speed up my development. For those experienced in the field, what are your suggestions for me to catch up? I started checking jenkins but still not sure if I should pump out some study days hard on it.

@BryanFinster 2 роки тому

The hard part of CI is when you are working with other people. However, pre-commit hooks for testing, linting, etc. are things that are always good.

@rumplstiltztinkerstein 2 роки тому

@@BryanFinster thanks

@jessehorstman Рік тому

Are there some open source projects that are doing everything right? It would be cool to see it in action.

@THEMithrandir09 2 роки тому

We introduced GitFlow to bring some structure to our branching. Turns out stopping to branch does that too.

@mhcbon4606 2 роки тому

I remember back in the day when we were using subversion, we committed directly on master (trunk or whatever what that name was at the time), and others had to pull and merge before even considering to commit. And you did not want to catch up too late, otherwise you were running into merge hell AHAH Thinking about that today in the light of this whole video made me think it was not so bad...

@dafyddrees2287 2 роки тому

When I first saw the gitflow diagram I felt sick at the sight of all those arrows. Every one is a potential merge hell. It's great for the "muggles" (non-developers) that worry about what's in a release but never have to use git directly to resolve a merge.

@zauxst 2 роки тому

Why would solving a merge become a problem... Lol....

@dafyddrees2287 2 роки тому

@@zauxst You obviously have never used “MercilessRefactoring” - you must just leave inconsistencies and design burps build up everywhere… or spend almost all your time merging. You have never tried to do XP and CI properly. Lol…. (Why are devs so soften arrogant pricks?)

@zauxst 2 роки тому

@@dafyddrees2287 feels weird saying to someone that is a "devops" by trade that "you never have tried to do CI properly". Anyway, it was a question, no need to put your hand deep in your arse.

@dafyddrees2287 2 роки тому

@@zauxst I meet loads of people that do devops and dev “by trade” that haven’t ever learned to do things the XP way (including CI.) It’s pretty rare and getting rarer. You’re the one with the attitude problem here mate with your supercillious use of “lol” after demonstrating clearly that you don’t understand why lots of merging would be a problem getting in the way of “MercilessRefactoring” (yes, it’s a thing - if you dropped the attitude long enough to learn about it you’d answer your own question.)

@garth-baker-blog 2 роки тому

Great Video! Love the insight. Super interesting. Certainly raises interesting views :)

@FSEAirboss 2 роки тому

How do you handle cross team dependencies where say you have a agreed on a new interface for persisting data, but lets say the business logic developers have completed their updates before that is finished and push their changes after red/green/commit locally passes in local testing with mocks, but the persistent code dependencies are not in master and the system breaks. Do you have your PM's force order of development so required dependencies are in place before other dependent code is started? What if there is more then this simple 1 to 1 requirement? What if the changes need to be done in parallel across multiple organizations and you can't stop one code team from doing anything or you now just doubled or more your dev time due to waiting? The other part of this scenario is what if you have a complicated change you are making and you anticipate that there are going to be perhaps hundreds of updates to that current branch. Does all that intermediate code that might not be used, now get pushed out to production perhaps bloating the code/cache/storage/etc. with dead space that is not active? Support for Legacy systems with high technical debt incurred over the years and management now wants to use the 'new' way of doing things with the old code because they don't want to pay for rewriting new code? I think we called it 'Agile-fall' (or maybe Agile-fail :p), all the motions, morning standup, etc..., in the end was back to a more traditional feature branch release with just a lot more meetings because the codebase couldn't support it, and where they forced it the technical debt just increased. I know, I know, find the seams, reduce coupling, interfaces, and modularize. Most system managers are going to scream if you try doing that to stuff they feel is working good enough, and management generally has pressure from above for new stuff, and not making old stuff better/quicker to add new stuff. Viscous cycle. Greenfield with a solid starting codebase architected to support this along small focused team I imagine this is almost like magic in turnaround times. Understand I am not at all saying this is bad, but its just another tool in the box to use when you have the appropriate environment that you can exercise it in. I think you called this out in this or another video, but do what you can in what you can control. No one else using unit testing but you? Then when a bug shows up you can more confidently say not your code and here's the reason (not withstanding bad requirements of course.) Perhaps there are answers to all these points, but I have never had the opportunity to hear them, or see them in practice. Perhaps if I watch a few more of these well thought out training sessions by CD I will get there 😃

@MartinSchonaker 2 роки тому

Thank you so much for this. I've been arguing against GitFlow for ten years. Next please debunk versioning using release dates or git commit IDs.

@dardanbekteshi3177 2 роки тому

Just curious about debunking versioning using git commit IDs? Why is that a bad idea?

@Marco9603 2 роки тому

How do you handle code reviews when everybody commits to master all the time? Don't you ever make pull requests?

@ottorask7676 2 роки тому

Continuous code review using ensemble working is a good option. You cannot inspect quality in afterwards anyway, so the best way to make sure you ship working software is to review while writing it, using two or more brains at the same time.

@KaratePath 2 роки тому

Nah there are many testing tools that can be used also with branching and the whole branching> pipelining> CI/CD cycle only with one branch is not selling it to me

@design2seo669 Рік тому

I must be missing something. If the features are merged before there done daily how do we keep form breaking master?

@ContinuousDelivery Рік тому

We don't commit changes that break it, and when we do by accident we fix them immediately, that is how CI works.

@bluesillybeard Рік тому

I just do what makes sense for each individual project. I generally have two branches: in-progress and stable. In-progress for things that aren't ready for release, and stable for things that can be shipped to the user. But every project is different - different scale, different team, different goal. And what works for your project will probably need more thought than a 15 minute video can determine by itself.

@harleyquinn8202 9 місяців тому

Why don't you have just one branch and just mark stable code with a release or version tag?

@bluesillybeard 9 місяців тому

@@harleyquinn8202 Because a lot of the time, people (like myself) download and compile the source code directly from the repo expecting it to work, and if it's not at a point where it's fully functional or even compiles, that's pretty disapointing. Anyone who uses Arch Linux is familiar with git packages, where installing an application or library does exactly that; download and compile it locally before installing it, rather than using a pre-compiled binary.

@LimitedWard 2 роки тому

I don't mean to sound contrarian, but I feel like you didn't do a good job of articulating why gitflow is bad for CI in this video. You seem to imply that it makes it harder to test your code and automate that process, but there are tons of tools out there which can trigger automated tests whenever a pull request is made. Why wait until the code is merged to run automated tests? Additionally, you mentioned that working directly off master gives developers more confidence that their changes are release ready, but this seems to make three key (and often incorrect) assumptions: 1. Tests are thorough and correct 2. Code is well written and meets the company's standards 3. Developers are only ever working on one feature at a time In reality developers are lazy and rarely test their code thoroughly, new hires will often write bad code, and developers are often forced to context switch regularly between tasks.

@kug07 2 роки тому

Well, my take on this, if you allow me, is that CI forces everyone to take a different aproach in how you develop software. For CI to work, everyone must learn how to break down things in smaller and releasable changes, and commit those changes regularly. And that this different aproach is overall beneficial and a better, more efficient way, of developing software. Not because someone says so, but because people who have worked properly with this different strategies found that with a CI aproach you create value way more often. It's not, by all means, an easy thing to accomplish, specially with bigger teams. But it doesn't mean it's not worth doing it.

@SmallSpoonBrigade 2 роки тому

If you've got simple code and can count on everybody using the most current version of your code, then CI seems like it might work out. As long as you know if the code is correct and reasonably secure. Honestly, if the code is that simple and short, then it doesn't much matter how you're handling the revisions, it'll probably work. But, if you've got something as large and complicated as an operating system, I'm not even sure how you would be able to apply CI in any sort of sane way. Sometimes, the best thing to do is to just use several branches and be done with it.

@BryanFinster 2 роки тому

We developers will do what we are incentivized to do. It sounds like the developers you work with are incentivized to use Grenade Driven Development where they are treated as a glorified typing pool with no responsibility for outcomes who toss the results over the wall for others to suffer with. GitFlow may hide that problem, but it's not fixing it.

@melmartinez7002 2 роки тому

@@andrealaforgia5066 "There is really no value in running tests on individual, isolated PRs. There is much more value in running tests on integrated code." In reality, as a matter of best practice, feature branches should be regularly pulling from the integration branch - yes, at least daily. That's where 'continuous integration' happens. With this pattern, the integration branch should always build & pass all tests and merge conflict resolutions should never have to happen on the integration branch. The 'one branch' advocates are defining continuous integration only as regular (i.e., daily) deliveries to the integration branch. With a feature branch methodology you still do continuous integration by regularly pulling _from_ the integration branch. The distinction is at some point just a matter of religion or favorite color, as working with one branch but using a local repo is just a different means of state separation, just as a branch is. Each means of separating state simply has different pros & cons.

@bl1tz229 2 роки тому

I cant agree with the title nor some of the content of this video…. Its simply misleading to say that gitflow is bad, since it works for so many teams and devs. In our team we maintain several environments (dev / test / acceptance / master) which each have their own testers. Some of the features (so feature-branches!) get accepted in dev before they go to test and acceptance, while some may be turned down. Similarly, this happens in the acceptance environment before going to production (master). In this case it’s easier to maintain environment branches and the individual feature-branches to eventually merge them in the target branch when it has been tested and accepted by the end-users of the environment branch prior to the target branch…. It’s not easy to explain it in words, but simply saying not to use certain techniques without nuance and ignoring the use cases it may have smells like bad teaching to me!

@ottorask7676 2 роки тому

TBD is more for agile organizations that appreciate fast feedback. GitFlow works better for gatekept waterfall-style and trust-lacking environments like yours, which is fine.

@miletacekovic 2 роки тому

How about feature toggles?

@jakobstengard3672 Рік тому

So when do you do codereview in this model, if you don't have branches and do pull requests? Pull requests really slows things down, but it also improves the quality because people tend to spot a lot of bugs and weirdness.

@ContinuousDelivery Рік тому

My preferred approach to code review is pair-programming, it’s a better review than code-review, plus a lot more other advantages. But there are other approaches too.

@mieszkometody 2 роки тому

In proper CI/CD - is there any place for manual testing? Should they follow a merge in which dev claims that feature is testable?

@andrealaforgia 2 роки тому

The aim should be to automate tests as much as possible. A human running tests plans with repetitive operations and deterministic results should be replaced by automated tests. Humans are best used for exploratory testing, where the human brain is what makes a difference. However, if you still need a human to look at the feature, you can do that anyway: keep the feature behind a feature flag and activate it in a test environment. A manual tester in that case is there to ensure the feature can be accepted for releasing, not that the code for that feature can go into master.

@krajekdev 2 роки тому

Dave is missing many points here. First of all, he is putting "continuous deployability" on a pedestal. In reality, most companies couldn't care less. The ultimate goal is to support the business and most of the time deploying rarely like once a month or quarterly is completely fine. Secondly, he is talking about potential conflicts and having out-of-sync copies of code. If team members are using common sense, these things happen very rarely and are resolved swiftly. In general, we should try to avoid marking tools as "bad idea, period". Both gitflow and Dave's idea of continuous integration are viable strategies with distinct characteristics.

@krajekdev 2 роки тому

@@andrealaforgia5066 Thanks for sharing your opinion. I would gladly hear more. Since so many people are favoring Dave's approach there has to be something valuable there, even though I cannot see it yet. a) 100% agreed that teams should integrate their work often. I am using gitflow, and everybody is integrating their work often(small PRs => short-lived feature branches + every PR is build/tested before merging to develop). It is hard for me to imagine, how giving up feature branches is better. I am happy to learn though. b) I may have just not experienced the problems you mentioned. By common sense, I mean stuff like talking to each other and recognizing that if you are working on this module, I will just do something else in a different part of the code. If there is a shared piece, maybe let's pair program a common part first. Again, I cannot imagine, how such an approach would leave to any substantial problems Dave is mentioning.

@TheMasterOfPeanuts Рік тому

Look at this! A sane comment in a sea of trunk-based zealotry. It's refreshing to see some nuance.

@mikhailbo8589 2 роки тому

actually, master is just a pointer to a commit as well as others branches :)

@edwardallenthree 2 роки тому

Pedantic AF. I approve of this comment.

@marshalsea000 2 роки тому

You're misunderstanding (wilfully or ignorantly) that there's two processes being discussed, that there's commits in both is neither here nor there. Wait until you get into the whole rebase vs merge argument that's gonna totally blow your minds...

@mikhailbo8589 2 роки тому

@@marshalsea000 I meant there is no any entity like "branch" in git. it is just a pointer to a commit for our convenience of working on commits tree :) there is only a single tree in git

@a544jh 2 роки тому

@@mikhailbo8589 There can actually be multiple separate "trees" in a repo. Not that it's common though.

@madm4ttus3r 8 місяців тому

Your task is to switch your frontend from react to svelte. It's going to take more than a day. Feature flagging this work would be rather difficult due to transitive dependency conflicts and application bootstrapping differences meaning having both react and svelte in the codebase at the same time is impractical. What's the CI trunk based development suggestion here?

@ContinuousDelivery 8 місяців тому

Well, it depends, and mostly it depends on how you designed the SW in the first place. If it is modular and nicely written, I could make the change for one, small, part of the code to try it out, and it if works out nicely I could commit that. We did this on one of the projects that I worked on moving between JS and our own, home-built, Web app framework, and Google GWT. The point is you don't start with a bunch of spaghetti code and say "Aha! Doesn't work here" you start by designing things to support a more incremental approach to development. You make code modular, cohesive with a good separation of concerns, use good abstraction and work to manage coupling. It is one of the reasons that I am not a big fan of the more complex "framework" style tech. They are too intrusive in terms of design. My real answer then, is that I can't answer your question without seeing where your code is now. It may be that the way you have implemented things HAS built a barrier to m making change more incrementally, but I would argue that that means that your code has some problems as a result. The fact that CI kind encourages us to care more about treating dev as an incremental thing is a positive to me, it means that it is a tool that helps us to do a better job!

@BozydarSobczak 2 роки тому

What flow should I use if I work on a all-or-nothing change under time pressure in a big legacy system which I barely know and my manager can't decide anything unless he tries it?

@sebad_informatica5696 2 роки тому

The flow of swtiching jobs

@mareker 2 роки тому

Continuous delivery is not continuous deployment. You can deliver to you manager and let him (and possibly some QA engineers) test daily. What is important is that they test what will be released. Not some dev/stage/feature branch.