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

  1.  @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
  2. Continuous Delivery does not equal Continuous Deployment.
    1
  3. 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
  4. 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
  5.  @MaxYoung-Maxinfet  And my response was deleted. Awesome.
    1
  6. You mixed up Delivery with Deployment... it's the other way around!
    1
  7. And why would you think something like that?
    1
  8. 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
  9.  @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
  10.  @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
  11.  @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
  12. "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
  13. 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
  14. CI is not the same as Continuous Build. CI is a practice, not a tool.
    1
  15. 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
  16. ​ @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
  17. "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
  18. 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
  19.  @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
  20. 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
  21. @ 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
  22. The opposite. CI has it's basis in XP (agile++).
    1
  23. Huh?
    1
  24. While I disagree with most of Primes comments, can we please not resort to ad hominem attacks?
    1
  25. 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
  26. ​ @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
  27. Dave would disagree. Having environment branches is antithesis to CI/CD.
    1
  28. 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
  29.  @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
  30. Huh?
    1
  31. That won't happen when practicing CI. Personal incredulity is not an argument.
    1
  32. 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
  33.  @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
  34. 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
  35. 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
  36. Please define "craziness".
    1
  37. 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
  38.  @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
  39.  @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
  40. 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
  41.  @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
  42. 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
  43. And you'd be wrong!
    1
  44. No you don't! That's what the "red" in the cycle is for!
    1
  45. 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
  46. "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
  47. 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
  48.  @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
  49. 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
  50.  @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