Comments by "Daniel Sandberg" (@ddanielsandberg) on "ThePrimeTime" channel.

  1. Continuous delivery is a way of working (with a lot of automation) to ensure only good builds makes it to production. It is a falsification process where the "bet" is that the build is a release candidate that will pass the crucible and make it to production - but most builds won't. CD is the codification of the organization's processes and SDLC cycle so that every change is verified and has an audit trail instead of process theatre where everyone pretends the process is followed and done doesn't actually means done. Continuous Deployment is the same as Continuous Delivery but the final human "approval gate" is automated. Continuous Delivery is not "every commit goes straight to production".
    108
  2.  @ChrisPatti  Yes, context matters. The issue is when organizations optimizes for "open source, zero-trust workflows" and "we have juniors, must control them" and "we can't have seniors to hold their hands" and end up implementing processes and workflows based on the lowest common denominator. And even worse, they tend to implement it across the entire organization by edict, again missing the different contexts. Working with CI/TBD is not "unprofessional" just because someone made a video on youtube saying "Use git like a professional". But it's at that level we are as a software industry. And it's sad.
    19
  3. Not that I like Uncle Bob, but he has been saying for a decade that we SWEs need to level up and expect higher standards, or when something really bad happens and 10000 people die, the governments of the world will. They will tell us what languages, tools and processes we must use. They will demand certifications for everything and require us to sign a form liability for every release. Because we didn't set higher standards ourselves.
    17
  4. Good OO is very close to FP in many aspects. Well constructed objects are nothing but a set of partially applied functions. Typical OO in the wild tend to be more class oriented programming than OO. And isn't a Monad a special kind of object implementing the monad interface?
    14
  5. "discover footguns as quickly as possible by firing them as many times as possible *before we hit production* systems". Fixed it for you. Continuous Delivery is not Continuous Deployment.
    11
  6. Velocity is a measurement, not a target nor a promise. So how can your "velocity be off"? The point is to tell you some kind of real rate, not the wished, hoped or estimated rate. That there are other things taking time, unpredictable things, is normal but should be managed to not overburden. Of course if you've been doing 5x more support than expected it may mean that the way you are working (development practices, testing, documentation, refactoring, monitoring, logging, planning, etc) need to change so that you don't drown in support. Something about a self-inflicted wound. I find the argument about mixing dev + test time as very odd. Untested, unfinished, undeployable features are worth nothing. There's no separate point-system for devs and testers. It's either done or not. I loathe developers that declared "I'm done", throws it to a tester and starts working on the next thing, and it doesn't even work. If you have a culture where there is a blame game of "you didn't meet your commitment" or "who estimated wrong" the organisation have not understood anything and you should either change your organization or change your organization. Tip: Remove the columns "ready for test" and "in test" from your board and only have todo, doing, done. If it's not tested it's not done and NO ONE gets any points, gold stars or pats on the back until it's actually done! The point of agile is not about processes, story points, burn-up, burn-down, sprints, etc, stuff. It's about giving everybody a healthy dose of reality so that the team and organization can adapt and change early, instead of hope that whatever "wishful plan" people have made will actually happen.
    7
  7. You don't "have CI". You practice CI. CI is much more than "a build management system that checks stuff". Can we please stop redefining CI to mean "whatever we're doing with branches and Jenkins" on this project!? The problem is that vendors say "buy our build tools to have CI" and people don't know what that means, just like people say "refactor" when they mean "two weeks rewrite" - not the same thing. If someone pushes broken crap without running the full build and test cycle locally first, they broke the social contract - don't push broken shit. If you do end up breaking something the build system tells you that, you have 10 minutes to fix it or revert it. if you ignore the issue, anyone else has the right to revert your changes. If you can't make it work again - the entire team stop what they are doing, huddle around and fix the problem. It is more important to keep the system in a good state and improve daily work than to work on more feature on-top of a broken system. But but but but... master will be broken all the time! No it won't because everyone will have to learn code hygiene and work in many small atomic changes. With branches you are actively ignoring that problem by isolation, branches are often broken for hours or days and no-one learns code hygiene.
    5
  8. FB/PR opinions reminds me of a cult. See how that works?
    5
  9. If everyone is working on a bunch of feature branches and only occasionally merges back to master - how will a rebase off master help keep all these feature branches up to date with each other? They won't, you'd be rebasing nothing, because all the changes are isolated - which flies in the face of CI. And he does not work alone. Read up on LMAX and what he and the team did there, without branches or PRs.
    4
  10. When I was younger I thought HR meant "Human Relations". Imagine my confusion once I found out it meant "Human Resources". If you think about it, resources are things that are USED UP. Are you being used up? That is why May 1st is "No Resource Day" and when if a manager calls you a resource you should call them "overhead". :)
    4
  11.  @robertminardi4268  Ok, you made it sound like there was a lot of finger-pointing going on. I might be projecting a bit. PTSD. I agree with using something more like kanban. However, the point of measuring velocity is to have some kind idea how much you got done each timebox. Now, I'm not a fan of estimations (too much WAGS and micromanagement), but if the team keep cramming more into the next sprint in hopes that they will catch up, they're not taking into account the velocity from the previous sprints (which kind of tells you how fast you're really going - i.e. capacity). Reminds me of the problem we had with trains about 10 years ago - the trains were late in the winter due to snow, the estimates on the boards was based on the faulty idea they would be able to "catch up". Of course that never happened, every station was a few minutes later than the one before and the end destination was 20-30 minutes late. I have a feeling you know this instinctively already. It's frustrating when it feels like it's the bosses that's causing the chaos... PS. I like this video, it's a great resource when wrestling with the dichotomy between work and management: "XP Days 2013: Dan North - Why Agile doesn't scale and what you can do about it" PSS. The noestimates movement was big 5-10 years ago.
    3
  12.  @ruperth.  "these people"... great argument. Why don't you approach Dave directly and ask him about his experience and what kind of project and software he has worked on instead of sitting here throwing out nonsense that he has never done any real work. Like the other 1241 in this thread that has made the same non-argument so that they can continue to clap their ears and yell la la la. And no it's not nonsense. I have worked with TBD/CI for almost 20 years in highly regulated markets. We have on occasion been forced to do FB/PR and it always resulted in worse outcome, more people leaving and slower development. So do not tell me it is nonsense. You know what is nonsense? All the people praying at the altar of FB/PR, denigrating us that has found a different way of working and yet I bet most proponents of branch-based development have never not worked with branches and as such has no other argument than ignorance to stand on.
    3
  13.  @MaxYoung-Maxinfet  ​ I think you misunderstood. I am squarely in Daves "CI/CD with no branches" camp and absolutely abhor branch-driven development; especially environment branches. A merge to master is NOT a deployment to production. What I meant is that I have never deployed a branch and that I cannot understand where the idea that "master represents production" even comes from. I deploy an immutable versioned artifact. I have never treated master as production. I treat production as production. I use tags, references and versions. Although I do treat master as if someone may deploy the latest build to production while I'm out on lunch.
    2
  14. Sounds like a bunch of programmers not knowing what they were doing and as usual the bad experience gets turned into "OOP is bad". If developers spent even half the time, they spent on complaining about things they don't understand, on actually understanding the why of things this industry might stop being such a sh*tshow.
    2
  15. You are the 10000s person to argue that point. And it's incorrect. Let's say you have 30 developers, each with their own feature branch. Even if all of them rebases from master every hour - how many changes are integrated to the branches? None? They stay continuously isolated and you won't know which branches that conflicts with which other branches until one of them is merged into main. CI/TBD is about exposing conflicts early by continuously integrating into mainline. It's nothing strange. What is strange is the obsession with branches to isolate changes and hide systemic issues.
    2
  16. And you'd be so wrong. Like so many others in this comment section you're engaging in ad hominem, red herring and bulverism. Just because you probably have always worked branch-driven does not make him wrong. Maybe not attacking people because they show you a different way of working. And a way of working that has been around for over 30 years at that.
    2
  17.  @ruperth.  Wait? What? Who is hurting whom, how?
    2
  18.  @ruperth.  What methods? You mean corporate scrum (which is not agile)? You mean corporate devops (which is not devops)? You mean corporate CI/CD (which is not CI nor CD)? You mean the incompetent management that just want to slap those terms on top of whatever they are already doing? You mean developers that haven't spent a second actually trying to understand anything beyond technology masturbation and sitting alone in their corner getting paid to do their hobby? You mean those people? You're hating the people that do not want to learn and then blame the "thing" for their failure.
    2
  19.  @ruperth.  Because people takes the path of least resistance. They don't want to spend time understanding. People inherently don't want to change and will find any excuse not to. And the result is junk. Not because of the ideas but because of people being people. The hardest part of learning something new is not learning the new - it's to unlearn the old. All of these things requires a deeper understanding in how work works. They require that the organization actually change. Again, we're not being paid to do our hobby and yet that is how most people in the software industry acts. My grandpa refused to try pizza his entire life. A few weeks before he died we tried to have him try it. His answer? "Why would i pay for pancakes with ketchup?" And that is the same misunderstanding people have about all this XP, agile, Devops, CD... they do all the cargo-culting motions with burnups, burndowns, story points, standups, sprints, etc and then a few years later all the developers are going "I hate agile". Not understanding that they did it to themselves.
    2
  20. Inherent complexity vs. Accidental complexity. Accidental complexity = technology complexity * technology m*sturbation. We are very good at j*erking off!
    2
  21. No. 357 person using the same argument. My response is the same as always: It's very simple. Git is everywhere, every tool, every integration, every provider, course and tutorial is using git. Of course we'll use it. "We're using git, therefore we must use branches" is a ridiculous (and is quite frankly an ignorant) position to have.
    2
  22.  @cronnosli  Yes. But he was working on the largest, most mission critical, open source project of all time. With 1000s of more or less untrusted contributors all over the world. If you find yourself in a situation where collaboration and trust is that low in your team and organization you should probably ask yourself why that is and work on that instead. Optimizing for individuals to work in isolation is not a great way to manage a team or maintain a codebase.
    2
  23. That is because you weren't practicing CI, and by the sounds of it - didn't pay attention to the feedback and had a "team" of individual tasks over a team that collaborated. I have lead a team of six that managed 600 applications in a highly regulated environment where we practiced CI, PP, TDD and never used a branch.
    2
  24. TDD is about figuring it out as you go along, not upfront.
    2
  25. The problem is not "not using branches". The problem is that people do not know how to work together in a code-base without breaking things all the time. Adding branches to the work often just hides the problem - it's a band-aid for low trust organizations. It does have it's place in OSS and when bringing new people on. But to force it upon everybody irregardless of experience and skill level is how organizations slow down and experienced people ends up leaving, then being replaced by juniors, entrenching the need for branches and rules. It's a self-fulfilling spiral. PS. I have working in highly regulated iGaming for 15 years. We have always worked on main and the times we have been forced (by management edict) things did not go well. It IS possible and CI/TBD does NOT makes us irresponsible cowboy developers that "has never worked with other people on real projects".
    2
  26. The point is that when you have 30 developers, each working on their own branches for days on end, what does it help rebasing from master? You still won't know if anyone else's changes conflicts with all other changes until it's merged into master.
    2
  27. You mean that old guy that lead the team that made one of the highest performant online trading systems in the world (LMAX) with more than a year in production before the first production bug; by using these XP/CI/CD techniques, in java 1.6, over 10 years ago? What you just did (not the first person in this comment section I might add) is a form of "poisoning the well" in an attempt to preemptively discredit a person so you can dismiss anything presented.
    1
  28. I'll just copy paste from my other answer: Dave used to work for a company called LMAX. They practiced CI and CD and built one of the highest performant real-time trading system at the time, in java 1.6. They had to adhere to lots of laws and compliance while doing so, all while handling a large amount of transactions. They worked in a single repo, on a single branch and released to production once per week; it took a year for the first minor production bug to appear. Many of the devs has split off after the company was sold and started a new company (TransFICC) to continue on the same path, using the same CI/CD practices. Dave promotes whole team involvement, pair-programming and good acceptance tests in addition to TDD. Your arguments makes the assumption that CI/CD is risky and can only work in a narrow context; which would be so if the team/organization does not practice good software engineering. Maybe you are right in the sense that most organizations and people in SWE are mediocre at best and have collectively decided to keep it that way. This makes me sad.
    1
  29. huh?
    1
  30.  @TheBrazilRules  What does that have anything to do with TDD? I'm actually confused by your comment. Who have said anything about large up-front design? Did I miss part of the video?
    1
  31. You misunderstand. CI means that everyone's changes is merged and integrated into mainline at-least once per day (preferably much more often than that). If people are sitting with local changes for days on end, they are screwing up. I.e. your scenario is null and void.
    1
  32.  @markpaterson2260  So what did you exactly mean by "the dudes ISP dies or his harddrive goes to shit"?
    1
  33. What is your definition of CI?
    1
  34. Push to master/main is not deployment to production.
    1
  35. I wouldn't say he (Dave) is mixing anything. From his perspective there can be no Continuous Delivery without CI, and at the same CI is not enough. While Continuous Delivery evolved in multiple places at about the same time Dave and Jez gave it a name and codified it in their book. They also named things like "deployment pipeline" which may confuse things for people not read up on the subject.
    1
  36. An answer would be an entire book. However there is a large misconception about CI/CD here... For the 437th time: Push to master does *not* mean deployment to production. CI/CD requires really good engineering, test automation, security and compliance automation so that the majority of "functional issues" *cannot* reach production. And the goal is to prove that the build is *not* ready for production as fast as possible.
    1
  37. What is this obsession with "deploy a branch"? What does that even mean?
    1
  38. ​ @scanrecs  With CI (and CD) we don't do that. Don't use branches to keep track of what should be in each environment. We build it once from main, stamp a version/tag/commit-ref on it and then don't change it. We then move that immutable version between environments, stages and approvals. i.e. what moves through the pipeline for the different environments is a version/artifact/tag/commit-ref, not different branches. There is an article on Hackernoon called "A Guide to Git with Trunk Based Development" that describes one way of doing it that way. Quote: "What version of each application is in staging? The answer is no longer “whatever is in the development branch for each project”. It’s 0.0.75, 3.15.1, 0.0.20, and 0.0.55. It’s explicitly defined in an environment repository. Meanwhile your production environment might be on www version 0.0.50 and content on 0.0.74. Also explicitly defined in code."
    1
  39. And when you have 30 developers, each working on their own branches for days/weeks on end, what does it help rebasing from master? You still won't know if anyone else's changes interferes with all other changes until it's merged into master. And that is always fun to discover 2 days before the deadline. So it creates even more issues because "what goes into a release is managed by merges" instead of manage it with opt-in/feature flags/configuration/etc. Feature branch workflow optimizes for isolation. CI practices optimizes for early detection of conflicts and issues by Continuously Integrating.
    1
  40. What happens with all that production code that needs to be changed, refactored, redesigned and removed when the requirements change? Oh, there is no difference, both are code that changes for the same reason! It's a false dichotomy! You're just making the classic argument that it's "bad/waste"; when the real reason is simply that you're looking for an escape hatch so that you don't have to do that new scary thing you don't want to do.
    1
  41. Because we're testing the expected behavior. Not that" the code we wrote is the code we wrote".
    1
  42.  @ghun131  I am not suggesting to "avoid doing support". I'm suggesting to figure out if/why a lot of time is spent doing support. Why would managers tell you how to do your job? As a team you need to figure out where the time is best spent, for the short term and the long term.
    1
  43. Dave used to work for a company called LMAX. They practiced CI and CD and built one of the highest performant real-time trading system at the time, in java 1.6. They had to adhere to lots of laws and compliance while doing so. They worked in a single repo, on a single branch and released to production once per week; it took a year for the first minor production bug to appear.
    1
  44. Dave pushes directly to main whenever possible.
    1
  45. Who has said anything about deploying to prod every day? Dave used to work at LMAX (a high performance online trading platform, so lots of financial laws and compliance). They had over 48 hours worth of tests (that's a lot!) that they were able to run in under an hour by optimizing and parallelizing the pipeline. It took them a year before they had their first production bug. They used CI/CD as described.
    1
  46. That is not CI. What you are talking about is continuous build. Continuous Integration is something different; it's a practice, not a tool, irregardless what vendors are trying to make us believe.
    1
  47.  @nefthy  Not really what I meant. Unless it's merged into main, built and passes automated tests, it's not integrated.
    1
  48. One of the main points of CI is that everything is always integrated in the main branch so there is no "integration cost prioritization" at the end. You can still have the code integrated without releasing to the customers. Either by build profiles (exclude features in the build), skip deployment of those components (if you have a more modular plug-in like architecture) or feature flags (where the features are included, but are disabled/hidden/opt-in by configuration or license).
    1
  49. In which way is he wrong? Where does he say that there are no other environments?
    1
  50. Don't enable the unfinished features using feature flags! All other changes in the code shall work, which is why automated testing is important. We do this all the time in Java/Kotlin/Go and it works just fine. Perfect when rewriting a component; just a flag if it shall use old or new implementation and flow. If the new implementation/feature doesn't work - just disable it. Need an emergency fix? Just make it and deploy! It's always deployable, even with unfinished features committed. In CI/CD the emergency hotfix process is exactly the same as any other change (except that we may skip days of performance testing). I can ask a question back: What if you have a bunch of features in the development branch. There is a deadline, but 3 out of 10 features that are merged are not in a releasable state due to finding bugs late? What do you do? 1. Revert a bunch of merge-commits at the last minute and have to re-test everything overnight? - Which may cause breakages in other code that had to be modified/refactored due to changes made to accommodate these 3 features. - Leading to people becoming afraid of refactoring and then process is added so that everyone has to ask for permission, time and budget to refactor. - Leading to increase in tech debt, stress and whatnot. 2. Taking cherry-picked commits from dev to master? And ending up with a master with a combination of commits that has never been tested together? - Even harder with the anti-pattern of doing squash merges from feature branches. - And all the other problems from (1). 3. Making another "release branch" and cherry-pick so that it at least can be tested in isolation. - But now ending up with yet another "truth" of the system? Have fun merging back and forth like it's 1997. All of this just creates complexity. The organization ends up hiring release managers, starts doing a lot of planning, processes, gatekeeping, Gantt charts, inter-team dependency management, etc. CI and TBD removes 90% of the problems. But it requires engineering beyond implementing the task and moving on to the next.
    1
  51.  @YPLabs  Some things are harder than others. If it is changing an existing page, try do it by making many small changes. And if there are some elements that should not be visible yet, use a flag (templates and SSR components are full of conditions anyway). If it is new/replacement UI then duplicate the pages and rewrite them, have a router based on some criteria of which one to use. Sometimes we end up in trouble when switching from framework v1 to v2 and we get conflicts. There are ways around that too. It may be so that in that case the team makes the choice to actually use a branch, with the understanding that "this is our focus 100%" for next few days and no other work will be done, with the risk of we have to spend a lot of time in testing. If it is more complex than that and will take weeks or months then branches is out of the question. The most common way around that is to first "shadow" framework v1 (i.e. repackage and change the package name, paths and/or namespace) and update all the current/old code to use the new imports. Then migrate one page/component at a time to framework v2, have a router based on some criteria to select which implementation to use. Then throw away all the old code once it is know to work in production and remove all the flags. Now I know that frameworks like React and whatnot is horrible when it comes to situations like this. There are always exceptions. The problem is when the strategy/band-aids to manage exceptions becomes the norm and just pretend that the problems isn't there. The problem I was trying to exemplify was that the three "not quite good enough features" held up the other seven because everything is based on if it is merged or not. Management are usually not that happy when they have to postpone a release of some features they have promised customers because of some problem with other features. CI/CD is meant to solve that issue.
    1
  52. Continuous Delivery does not equal Continuous Deployment.
    1
  53. The Strategy Pattern is a specific application of Polymorphism and Composition. In-fact, the majority of the patterns in GoF are different applications of those two concepts. At the abstract level, good OOP looks very close to functional programming, it's just that most programmers learned "class oriented procedural programming" and thought it was OOP - hence people do stupid things like - IThing (.NET yuck), ThingImpl (Java yuck) or AbstractFactoryProviderBuilderManagerHelper (**dies**).
    1
  54. CI/CD does not mean that "trunk goes directly to production" - whatever that means. I have never understood that sentence. I have done this professionally for 15 years. I have never "deployed master".
    1
  55.  @MaxYoung-Maxinfet  And my response was deleted. Awesome.
    1
  56. You mixed up Delivery with Deployment... it's the other way around!
    1
  57. And why would you think something like that?
    1
  58. Can we please stop with the stupid "just use SVN then" non-argument BS? And then also making ad-hominem attacks (calling people "nutter") takes the cake. You are the 3245th person making the same argument without having a clue what you're talking about. It has nothing to to with git or SVN. It has everything to with systems thinking, sociology and engineering. If you cannot see past "must use branches because git" then what are you even doing?
    1
  59.  @codingneko  CI/CD is not testing in production. Merge to main is not a deployment to production. In CI/CD the merge to main is where testing starts, not ends. CD means Continuous Delivery, not Continuous Deployment.
    1
  60.  @codingneko  Why do you assume that testing on a separate branch is any better than testing on main? If you missed it on main, you'd have missed it on the branch too. If you caught it on the branch, you would have caught it on main too. What do you mean by "You're deploying to production"? When? How? There is nothing in CI about deploying to production! All the testing happens *after* merge to master. Master does not equal PRODUCTION! Master equals the truth of the system from whence all builds stems from, some of which *may* make it into production.
    1
  61.  @codingneko  No. Because a merge to master is not universally a deployment to production. Why do you repeat that claim as if it were an absolute truth? Can you accept that there exists a world where we can work directly on master and that does not mean that every random commits ends up in production untested? Because that is your claim. And I just told you that is not the case, but you keep arguing that is the case because you cannot see beyond git branches. I've done this for 15 years. Built mission critical, highly regulated software. I have never used a branch except when there was no other choice. I have never ever had the concept of "commit to master is a deployment to production". I deploy builds - immutable builds that have been tested until deemed production ready. I have never ever "deployed a branch".
    1
  62. "I use Git, therefore I must use branches" is a ridiculous position to have. People are using Git because it's everywhere, SaaS, tools, integrations, etc.
    1
  63. SVN does not require pessimistic locking. Git was invented because Linus was working on the largest OSS operating system on the planet. With many thousands of contributors all over the world. i.e. a low trust environment for something really complex and mission critical for many users. Context matters. You can practice CI with any version control system and has nothing to do with "old time VCS". Using branches for the sake of using branches sounds odd to me.
    1
  64. CI is not the same as Continuous Build. CI is a practice, not a tool.
    1
  65. My comment was deleted for some reason, so here is the short version: Instead of arguing from personal incredulity and against the person, please do some research (about CI, CD, Dave Farley for example) and argue the point. Instead of insinuating that people that's not doing what you have been taught (FB/PR/gitflow) as "inexperienced unprofessional cowboy developers that has never done any real work", maybe take a step back and try to reflect upon how it could be done differently than what you are used to.
    1
  66. ​ @aprilmintacpineda2713  I know that when there is something "new" people just want a set of rules and steps, a recipe with 5 steps on how to do it. Many things are more abstract and requires experience doing the thing, take the time to form a deeper understanding and once "it clicks" it's obvious and you no longer need the recipe and you just do. There is no "do these steps and you're CI", that would be nothing but cargo culting. We actually have to do the hard work and change how we work, think, behave, incentivise, collaborate, communicate and understand how work actually works. The amount of programmers in the world doubles every 5 years or so. About 10-12 years ago everyone went nuts with FB/PR/GitFlow and thus we can approximate that 75% of all programmers have never practiced or seen real Continuous Integration. From that we can also say that at any point in time 50% of all programmers has less than 5 years of experience. Then the practices that this industry was build on are forgotten and completely alien to all the new people, because most people do not learn, they are being taught, then they iterate that teaching to the next generation as the "one true way" and put in a lot of effort and rules, process, arguments and "personal credit" into that particular way. Then the people that's not doing what "you" have been taught are being told they must be "inexperienced unprofessional developers that has never done any real work". Context is king, and most people convince themselves that the thing they spent time "perfecting doing" is the right thing for all contexts. This of course goes both ways so we all need to be aware of our biases. The key is being able to adapt based on context, develop a deeper understanding of the system and not get stuck in doing what is convenient and be afraid of change.
    1
  67. "We use GitFlow at my company and we do CI/CD in Dev and then just CI in Prod." This sentence shows that you are doing neither. I won't even try to explain it yet again. I've explained the same thing so many times in this comment section that Youtube thinks it's spam.
    1
  68. Not true. What he describes can and is used for complex, large scale and highly regulated systems. What you just said is a typical "response of incredulity" to CI/CD: - It won't work here. We're not making websites, we're an enterprise! - It won't work here. We're not an enterprise, we're making games! And everybody is a special snowflake.
    1
  69.  @xTheGamerHeart  Push to master is not equivalent to "committing to production". Where does this idea even come from? CI/CD requires that we actually automate the majority of the testing; that we treat tests as first class citizens, and security and compliance as features and not something that gets sprinkled on top after the code is written.
    1
  70. The opposite. When practicing CI, master always builds and passes the tests. That's the entire point! Multi-month refactor? Divide it up into many many small steps that always works, even if it's NOT THE PREFECT SOLUTION. No one will care that someone went back and forth and evolved the code until it's good enough to be declared "we're done with this for now".
    1
  71. @ Multi-year refactor is an oxymoron. You are talking about a massive rewrite . A refactoring is not a big rewrite, it's a small change that takes us one stop closer to some end state. Look up Strangler Pattern.
    1
  72. The opposite. CI has it's basis in XP (agile++).
    1
  73. Huh?
    1
  74. While I disagree with most of Primes comments, can we please not resort to ad hominem attacks?
    1
  75. This comment just shows the immaturity in the software industry. Instead of having a discussion people are taking things to absurd extremes in an attempt to ridicule an idea without having to have an actual argument. Throwing in strawmen, ad-hominem and arguing that you have to use branches when you're using git. Maybe it's time for developers around the world to actually sit down and read up on systems thinking, sociology and the history of software engineering instead of jerking off to the latest tech and frameworks.
    1
  76. ​ @NathanHedglin  Not if you realize this is the most upvoted comment on the video and then look at the rest of the comment section. Then you'll realize that it is a very common argument "Well, why are you even using git for if not for branches". So a lot of people absolutely takes it as a real dig against CI. And that is a real problem!
    1
  77. Dave would disagree. Having environment branches is antithesis to CI/CD.
    1
  78. No, this guy works with people that gives a shit beyond sitting in their corner, with headphones, typing code alone, essentially getting paid to do their hobby. Maybe you should start there instead of stating, with absolute certainty, that Dave must work alone.
    1
  79.  @darkopz  Well, this comment section has 100s of similar comments. Same arguments, over and over again. Yes, master may be broken every now and then. The important thing is to fix it fast instead of ignoring it and go home for the day. And then improve till next time.
    1
  80. Huh?
    1
  81. That won't happen when practicing CI. Personal incredulity is not an argument.
    1
  82. If the shared branch in broken all the time, the teams were not practicing CI nor CD. Most processes are scar tissue from previous failures. Culture and bad software engineering practices is what casues the problems. CI (as well as CD and agile) is about exposing the systemic problems early so that the organization has to actually fix them. This hurts, so most don't. Instead they add process (and branches, and handoffs and approvals) as a bandaid instead of actually fixing the root cause.
    1
  83.  @constantinegeist1854  Yes, sure you're right. Being good at CI/CD requires some skill. Skill requires deliberate practice and training. How many devs have you met that looks beyond new tech or next framework and actually tries to build a deeper understanding of the system they work in?
    1
  84. You are the number 53356th person making the same ridiculous "just use SVN" argument. Read the comment section and see that you are not alone. Dave led a team that made one of the most performant online-trading systems in the world at the time using these techniques. They deployed to production about once per week. They always worked on mainline. I have done this for 15 years with highly regulated software and never used a branch if I had a choice. We were 6 devs, 4 testers that maintained 300 backend apps, built one new app every 1-2 months, maintained the frameworks, libraries, builds, documentation and test automation. We never used a branch. What you have misunderstood here is that developers makes sure that their changes works locally before pushing to reduce time wasted on a broken build. I.e. giving a sh*t instead of treating version control as some kind of "no idea if this works" dumping ground. The point of CI is to make sure that there is a single truth of the state of the system, to expose issues early and as well as to expose organizational problems. The point of CD is to do everything possible to prove that the build is NOT production ready and to put pressure on the system of work to improve. And, yes you can have merged code that won't be released for the next two months. In CD there often are no hotfixes, there is the next build and the next deployment.
    1
  85. You are not even arguing any point, you're just dismissing everything out of pure incredulity. You are the 353123th person making the same dismissal without even any attempt of a discussion "he must never have worked on real projects". How come that it's always the people that made the least effort to understand something and knows the least about a subject are the ones most sure that they're right, and then makes underhanded ad hominem attacks to top it off?
    1
  86. Please define "craziness".
    1
  87. Staying up to date with what? All the other changes are on feature branches as well. You can rebase all you want, you're still not getting the other changes and won't know if something is conflicting until one of the conflicting branches is merged. And that is the damn point. CI has a 25 year track record. It does work, but it requires different skills and a different approach to development beyond the typical developer sitting alone in their corner with headphones, typing code until "it's done".
    1
  88.  @pinatacolada7986  That's the oddest attitude ever. The entire point of CI is to bring any conflict to the surface as early as possible to avoid late surprises and always be in a releasable state. "If it hurts, do it more and bring the pain forward" is the mantra of CI/CD and kind of the basis of agile too. There is a reason we have the old saying "the last 10% of the project is 90% of the time"!
    1
  89.  @pinatacolada7986  Arguing from incredulity and calling people idiots is not constructive and quite frankly shows your inexperience. "I use git, therefore I must use branches" is a ridiculous position to have. This discussion is over.
    1
  90. CI/CD is NOT about releasing buggy software to production every day. If you think that is what it is you didn't pay attention and are dismissive of something you didn't even bother to understand. Nothing but an argument from ignorance.
    1
  91.  @MeriaDuck  Why this assumption in the comment section that Dave must only have worked on small simple projects every other day? Dave has worked in IT over 30 years (many of those as technical lead) on projects with more regulatory requirements and more complexity than most of us. Production is not a branch. Production is the servers our system is running on. Production is the user devices our apps are running on. Production is the modules in a car our software is running on. Personal incredulity aside. Practicing CI is a skill. It's hard. We as developers must learn how to make many many small changes that always works instead of sitting on a branch for days on end. We must learn to automate tests and take the lifecycle of the software (in production) into account. We must learn to collaborate and work together over sitting in a corner with headphones, working on individual tasks and "cooperating" using Jira tickets (or PRs). We must stop thinking that testers (or some enterprise testing/compliance group) approves of changes after the fact. CI/CD/DevOps/Agile requires that the culture of the entire organization changes - most don't and conclude that it doesn't work.
    1
  92. What do you mean? If it's finished it is merged (pushed to origin main) and passes all the automated tests! "I coded it" is not good enough! Secondly, if properly practicing CI you can merge/push incomplete (but working) features to main many times per day and thus the problem almost disappear. The scenario you describe is more of an anti-pattern prevalent with complicated feature branching processes. Typically working on a feature branch, make a PR and while waiting for review start working on some other task that builds upon the not yet reviewed PR which may have to undergo major changes. A common question in forums is "should I branch of the feature branch while waiting for the reviewer?" Which is the wrong question.
    1
  93. And you'd be wrong!
    1
  94. No you don't! That's what the "red" in the cycle is for!
    1
  95. Watch: "The Rationale for Continuous Delivery • Dave Farley • GOTO 2015" "How to Build a DEPLOYMENT PIPELINE? (Continuous Delivery)" "Continuous Delivery Pipelines: How to Build Better Software Faster • Dave Farley • GOTO 2021"
    1
  96. "So instead of going through a security gate before entering you get scanned while in the building and gets shot if the scan finds anything illegal." Jag är död! 🤣
    1
  97. No one has said anything about deploying to production every day, specially without proper testing and checks! I understand that you come from a place where everything is branch-driven, but at least try to think about other ways of working that isn't driven by branches. Have you read the Continuous Delivery book by Humble and Farley?
    1
  98.  @cronnosli  Of course not. But that is the primary reason of why it was created. Just because something is popular doesn't make it the best. Just because organizations has adopted the open source FB/PR practice does not mean it's the best. Just like Kubernetes and microservices. Organizations has adopted it whether they need it or not, getting bogged down in complexity. That doesn't make it the best. Most organizations has adopted these things because "it was popular" and they were "told to", not because they made informed decisions.
    1
  99. There is nothing inherently wrong with UAT/staging. CI/CD does not preclude having many environments, it's the opposite - it enables them. Not sure what the confusion here is. "Or the possibility of merging from develop all the time." Unclear what you mean by that.
    1
  100.  @MaikKellerhals  Yes. No. The key is to take many many small steps. Much smaller than you think. Just enough to get to get one little generic step to pass as a time. And in doing so we discover what of our assumptions is right or wrong and if we're still on the right track. Joe B. Rainsberger has an online course. The first 2 chapters are free. It's called "The World's Best Intro to TDD, Level 1" (video links are in the middle of the page). GeePawhill has a bunch of videos on his site and vimeo, switch, etc.
    1
  101.  @MaikKellerhals  I answered and got shadow banned as usual.
    1
  102.  @MaikKellerhals  I can't convince you unless you make it an active choice to learn and try for some reasonable amount of time. If you're waiting for someone to convince you out of "tdd sucks the fun out" you will never find it.
    1
  103. "The CI?" I don't think that word means what you think it means. By the way. In the CI way, the instant feedback is 10 seconds away, on my workstation, before I make commit.
    1
  104. One of the companies where Dave worked made the highest performant trading system at the time, in java 1.6. This was a real-time trading system; which means a lot of laws/compliance to adhere to and large amount of money being exchanged. They where able to optimize their system to run 48 hours worth of acceptance tests in an hour.
    1
  105. What is wrong with working directly on master?
    1
  106. ​ @thefekete  Nope. I have worked like that for 14 years, on highly regulated, mission critical, finance applications. With teams from 4-50 people, maintaining 100's of services. Working directly on master is awesome. But arguing that it's somehow "wrong" must come from having only experienced branch-driven development. I have gone from TBD/CI with awesome results, to feature branches (by management edict) with bad outcomes, back to CI and bounced right back up.
    1