@DisturbedNeo
You know, you might want to make sure the stakeholders get the full context of the application, otherwise they might not sign off on stuff to go into prod, so what you can do is make a separate branch that runs parallel to main, and when it gets pushed, there's an automatic build and deployment to an exclusive environment only the devs can access. And then the devs could branch off of this dev-exclusive branch to work on their features, and make sure everything is bundled together in a single release to pre-prod. And then, you could have a temporary branch for releasing to pre-prod, so you can push any last-minute bug fixes before it gets to the stake holders, and of course that would merge into both dev and main simultaneously to keep everything up to date. But that process is getting a bit cumbersome, so to keep agility high, we can also have branches for hotfixes that branch off of main, and after we fix the bug it gets merged back into main and dev to keep everything up to date. phew we did it boys, we fixed trunk-based development. Wait...
@cod-the-creator
Seems like a bunch of risk and added overhead just so people don't have to deal with as many merge conflicts.
@BrianBest
Imo for 80% of companies feature flagging or dark shipping is mostly fine. I think once you get in to SLA’s with required uptimes it becomes more prudent to have a slower time to production cycle
@jishu44
This is best ❤ Thanks Wdc
@patricknazar
These videos are super useful.
@Brinabrin
Great presentation.
@isodoublet
You should definitely not merge everything into main. It should have its own place. Main should be the function that starts the application, that's it. It can do some setup, teardown, define the API, but that's it. Create proper classes and functions for the rest.
@miguelsantiagovelasquezrui765
I remembered the time when I suggested to remove the whole testing process when someone wanted to change simple files like translation files to speed the process of a PR, but it was not accepted because Cloud Engineering is another team, and to go with this process could be hard. I don’t know if Cloud Engineering helps devs or just makes more difficult our lives :/
@markl5044
Is the expectation that your feature branches also have their own infrastructure so you don’t have to test your changes locally? How is local development done in a way that you can appropriately test what you’re coding ?
@manoj-k
Can you make a video of building an npm package which is a plugin for tailwind css like Daisy UI(no need of any components) and the complete process about deploying it to npm.
@k98killer
Would you consider going over AI/ML tools/algorithms and where you have seen them used? (I'm currently working on low-level AI/ML stuff, so it is front of mind for me.)
@fikilekentane6982
..tnx .. valuable input 👌🏾
@harshvardhanray8095
Where's the link for the previous video?
@TrapCompany-xk9qy
Helpful video
@oOrbitZz
Interesting but how do you manage the deployment schedule on this approach. How do you protect stable codes if you keep everyone allowed to update? Like do you issue code freeze?
@pinkpantheonqueerhistory5699
The amount of "Make $$$$$$$$$$$$$$$" nonsense I had to scroll thru to actually land on this worthwhile video :(
@dontdoit6986
So companies bend over backwards to do Trunk development when gitflow works just fine.
@anj000
One crucial thing is missing in this video. It is called master branch 🤌
@joshmealing5372