This is why we use continuous integration
Вставка
- Опубліковано 19 сер 2024
- 🤖 SaaS I'm Building: www.icongenera...
💬 Discord: / discord
🔔 Newsletter: newsletter.web...
📁 GitHub: github.com/web...
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
I really like how you describe things in a "real" way. I always thought that there's something missing I didn't understand about CI, but it turned out to be just the limitations of it. There is no single conrrect way to implement it.
I look at CI as a mechanism that enables keeping environments in sync, by generating env artifacts based on code changes as soon as those changes are ready to be merged which is a consequence of your view on what CI is. I never had to deal with feature flags, so I appreciate you including it in this video and emphasizing that there is no "right" way of doing things; you usually do what works for your team/project/feature and go with the flow and adjust continuously.
Thanks for the informative video!
That last part is the crucial take on all of this
Great content, 100% clear!
Really interesting to see how you manage this from a 10 person Dev team perspective. At this size I'd expect a reasonable level of autonomy as to the exact process, but simpler is better. Working in larger teams that I've experienced, there is a greater clarification of module or platform ownership and priorities agreed by a model of assessing the impact to customers and business requirements. We moved to automated verification testing, that included qualification based on that priority model. There are at times areas of overlap and there would be a system team or bod that would resolve these questions with the developers or teams in question.
You're a psychic man!
Looks interesting. Will be trying it next time i work on a bigger project!
Awesome content
++Keep Going for ever
Good content!
you look great with the beard
Could you make a video about SSR vs CSR in Next JS, differences an when should which be used? Thank you.
Good job babe ❤
Great video. Interesting topic. How would you handle commits in this context? How does ci relate to commits?
What do you mean by handle commits?
@@WebDevCody Sorry for being vague. Would a git commit and a PR have a 1:1 relationship here or does it not matter? I’m trying to commit often but also only commit “safe” code. Would you do a PR and a merge on every commit or would you commit code several times before deciding on a PR?
Also, I appreciate the exploratory nature of your videos and that we get to follow your thought process rather than you serving pre-scripted solutions. It makes your content stand out. Keep up the great work!
@@stln768 There are 2 different branches here. The first one is the feature branch, where you work on, and the second one, the development branch, where the "stable" version is. If you do something and commit it, it goes to the feature branch. After several commits and once the feature is ready, you do a PR from the feature branch to the development branch. You can commit as often as you want, as you are not on the development branch.
@@Kennstduwayne1001 thanks for your comment. I get that. I was just wondering if they actually would commit freely in their feature branch or if they would commit code only when it was “mergeable”.
Hey Cody, nice video, unrelated, i saw a video about a tool called codeux or something whicj is a visual tool for creating a site that outputs react code and has vscode integration, if you try it please make a video
Can you do basic CI/CD integration for front-end dev?
Hi, what about feature revert in your team approach? I mean, for example, I pushed lots of subtasks of my feature to dev branch, and for some reason business declined the feature and I need remove all code I already pushed. Is there some sort of life hack how to do this ?
Personally I prefer to make a feature branch and merge changes from dev branch once/twice a day (I think it depends on size of the team). Also proper code splitting across different files helps to reduce merge conflicts.
Reverting merged code sounds like a nightmare. Especially if you had conflicts when you merged. I’ve also seen issues with git revert basically never accepting the same commits again if you plan to readd the feature. I think feature flags are probably easier
Feature flags definitely help to find parts of your feature across the code base)) and remove the code in case of the feature decline.
I never work with feature flags, can you make a video about it?
Ummmmmmm first