Well, that made a lot more sense than watchinf one of the "official" GitLab videos on the subject. Nicely done. One quibble: Git's internal data structure is a DAG (Directed Acyclic Graph) not a Linked List.
Please make a video on gitlab keywords and its usage, especially on how to use gitlab variables in the pipeline. E.g using aws access keys as credential to do terraform plan and apply on a specific account
It is really informative and nicely presented. For the env based branching strategy, where should I carry out bug fixing? I mean, after merging 'main' to 'pre-prod', if a test team finds some errors then fixing of those bugs should be carried out on 'pre-prod' branch Or 'main'? 1. If the answer is 'pre-prod' then should I fix bugs directly on 'pre-prod' branch or create 'feature' branch from 'pre-prod' ? (I believe this might not be a right approach as this will require merging 'pre-prod' bug fixed commit back to 'main' which would add complexity) 2. If the answer is 'main' then should I fix bug by creating 'feature', then merge 'feature' to 'main', and then merge 'main' to 'pre-prod'? Apologies for asking multiple queries in single comment, appreciate if you could help me clarify the doubts. Thanks in advance.
thanks for the video :) its very greate content, I just have a little concern about a thing, I share it with you: you create your feature branches from the master, after you finish you merge back to the main with merge request, you will run your automated tests, but at this point your code can contains bugs, thats why you test in staging/pre-production branch also (manual testing). So during this, somebody can create a new feature branch form the main branch wich can contains some bugs. Is this all right? My solution is: - create feature branch from main - merge to staging branch from feature branch with merge request - run automate tests (unit, e2e, etc..) - merge to staging, deploy pre-production/test environment - test you feature in test environment with others - create merge request to main branch - run automated tests again - deploy to production What do you think about it?
This is actually nice explanation, thanks , could you please provide and blog or pdf or any reference document for "GitLab Flow with Release Branches", as I want to implement and couldnt find on internet.
Hello, thanks for your comment! This is part of the reason why I created the video, because the documentation was somewhat incomplete and not available on the internet. I used the official GitLab documentation as reference for pretty much everything in this video iirc
Thanks a lot for the video. I like the env based branches strategy as it naturally relates to the environments a team usually has. So how should we go about the hot fixes in the env based version of the flow? This is not mentioned in the video. The fact that you assume only fast forwards tells me that it also should be a cherry pick from the main branch?
Cherry-picking of bug-fixes from main/master work only, when the main branch is still compatible with the release branch source code. That was the reason for the GitFlow approach, I guess. How does GitLab Flow solve this?
Thanks for the explanation, this was very helpful I have a question... we configure the repository settings to perform only fast forward merges (as shown in the Part 2 video) Doesn't this mean that the merge from feature-branch to main-branch is also treated as a fast forward merge? And hence no merge commits are allowed?
Hi, thanks for the great video. What i don’t understand is how i can tell GitLab to fast-forward merge only in the pro-production and production branch…. That’s exactly what i am searching for because it prevents me to merge the production back to main every time. Is there a setting for that?
What if you have a huge application with multiple installations across the world? These installations in general are the same codebase (with heavy configuration from the application) but with one or two instances of old versions that cannot be ported? Which git branching strategy is the best in your opinion?
If you are required to support older releases in the production environment, then a Release Branching strategy would probably better suited over the Environment branches.
Why do we need the main branch? Couldn't we just use a staging branch and a production branch? Feature branches could be created based on the staging branch and later merged back. The staging branch can be merged in the production branch when it's ready. If a bug fix is needed on the production while the developement is going on in the staging branch, we could create a hotfix branch based on the production branch, fix it and merge it back to production and the staging branch. What are the advanteges of having a main branch? What am I missing? Thank you!
If you don't have the main branch, then there is a good chance you'll find yourself rebasing from prod down to dev and piss everyone off. I will say this guys video is intriguing, but I prefer just to have a main branch for simplicity and that's it.
Thanks for your video! I am still learning different branching strategies for our work. However, we are facing an issue that we have concurrent developments for different features, but the feature release to production could be different. For example, feature 1 start development from 1st Jul and completed at 15th Jul, feature 2 start development from 8th Jul and completed at 20th Jul. However, feature 1 take a long time for UAT like finished at 25th Aug but feature 2 finish UAT fast at 5th Aug. In order to release the feature 2 asap, in GitLab Flow how can I release feature 2 at 15th Aug but the release does not include feature 1(because at 15th Aug feature 1 still under UAT)?
Thank for your video. I think Environment branches are suitable for SaaS that need deploy to an environment. Release branches are suitable for software that is a software simply, it don't need deploy, user will do that. If i have a release, beside, i want provide a release as a service, can i use both versions?
_" I think Environment branches are suitable for SaaS that need deploy to an environment. Release branches are suitable for software that is a software simply, it don't need deploy, user will do that."_ Yes, this is correct. _"If i have a release, beside, i want provide a release as a service, can i use both versions?"_ I'm not sure I understand your question, could you explain a bit more?
@@tech_with_moss as Gitlab, it provides releases and also provides Gitlab services to users. So can we combine 2 versions of Gitlab flow or is there another version of Gitlab flow
@@quyetthangcao6791 If I understood your question correctly, I believe that you could combine versions of the GitLab Flow to support a hybrid workflow.
TOC:
Introduction: 00:00
GitLab Flow Environment Branches: 01:20
GitLab Flow Release Branches: 11:13
Conclusion: 15:17
Wonderful breakdown of environment branches vs release branches.
By far the best video on this topic. Much better than everything GitLab puts out on this, for sure.
Thank you! I appreciate it!
Well, that made a lot more sense than watchinf one of the "official" GitLab videos on the subject. Nicely done.
One quibble: Git's internal data structure is a DAG (Directed Acyclic Graph) not a Linked List.
Another master piece. Moss does not stop surprising me. Thanks again for your time and effort to illuminate us. Best wishes
Thanks so much for the kind words. I really appreciate it and I'm very glad that these videos provide value
Awesome video!!! Thanks for explaining and sharing!!! Was able to understand GitLab Flow in 16 mins :D, awesome!!!
Thanks so much! I'm very glad you liked it and it was helpful!
Please make a video on gitlab keywords and its usage, especially on how to use gitlab variables in the pipeline. E.g using aws access keys as credential to do terraform plan and apply on a specific account
Awesome explanation! Thanks a lot for your effort and time.
No problem! I'm glad it was valuable.
Some of your work are amazing man and this is definitely one of them.
Thank you for the kind words!
this one is pure Gold!! Thanks for the effort
awesome video, makes learning gitlab flow soooo much easier!
Very helpful and valuable. Clarifies a lot. Thanks
I'm glad to hear it!
Great overview!
It is really informative and nicely presented. For the env based branching strategy, where should I carry out bug fixing? I mean, after merging 'main' to 'pre-prod', if a test team finds some errors then fixing of those bugs should be carried out on 'pre-prod' branch Or 'main'?
1. If the answer is 'pre-prod' then should I fix bugs directly on 'pre-prod' branch or create 'feature' branch from 'pre-prod' ? (I believe this might not be a right approach as this will require merging 'pre-prod' bug fixed commit back to 'main' which would add complexity)
2. If the answer is 'main' then should I fix bug by creating 'feature', then merge 'feature' to 'main', and then merge 'main' to 'pre-prod'?
Apologies for asking multiple queries in single comment, appreciate if you could help me clarify the doubts. Thanks in advance.
same question here
thanks for the video :) its very greate content, I just have a little concern about a thing, I share it with you:
you create your feature branches from the master, after you finish you merge back to the main with merge request, you will run your automated tests, but at this point your code can contains bugs, thats why you test in staging/pre-production branch also (manual testing). So during this, somebody can create a new feature branch form the main branch wich can contains some bugs. Is this all right?
My solution is:
- create feature branch from main
- merge to staging branch from feature branch with merge request
- run automate tests (unit, e2e, etc..)
- merge to staging, deploy pre-production/test environment
- test you feature in test environment with others
- create merge request to main branch
- run automated tests again
- deploy to production
What do you think about it?
Wonderful video. Subscribed!!!
Thnx a lot dude, you are best
Great video, very difficult to find detailed deep knowledge videos
Thank you so much. I'm very glad to hear that this video was helpful.
Awesome content🙂
This is actually nice explanation, thanks , could you please provide and blog or pdf or any reference document for "GitLab Flow with Release Branches", as I want to implement and couldnt find on internet.
Hello, thanks for your comment! This is part of the reason why I created the video, because the documentation was somewhat incomplete and not available on the internet. I used the official GitLab documentation as reference for pretty much everything in this video iirc
Thanks a lot for the video. I like the env based branches strategy as it naturally relates to the environments a team usually has. So how should we go about the hot fixes in the env based version of the flow? This is not mentioned in the video. The fact that you assume only fast forwards tells me that it also should be a cherry pick from the main branch?
Thanks 🙏.
Cherry-picking of bug-fixes from main/master work only, when the main branch is still compatible with the release branch source code. That was the reason for the GitFlow approach, I guess. How does GitLab Flow solve this?
Thanks for the explanation, this was very helpful
I have a question... we configure the repository settings to perform only fast forward merges (as shown in the Part 2 video)
Doesn't this mean that the merge from feature-branch to main-branch is also treated as a fast forward merge? And hence no merge commits are allowed?
Hi, thanks for the great video. What i don’t understand is how i can tell GitLab to fast-forward merge only in the pro-production and production branch…. That’s exactly what i am searching for because it prevents me to merge the production back to main every time. Is there a setting for that?
What if you have a huge application with multiple installations across the world? These installations in general are the same codebase (with heavy configuration from the application) but with one or two instances of old versions that cannot be ported? Which git branching strategy is the best in your opinion?
If you are required to support older releases in the production environment, then a Release Branching strategy would probably better suited over the Environment branches.
How to do if the production branch is a main branch?
Why do you suggest a fast forward commit instead of a merge commit from main to production branch
How you maintain binary integrity if code getting merged to multiple branches
What is the difference between staging and pre-production?
Its the time just different names.
Why do we need the main branch? Couldn't we just use a staging branch and a production branch? Feature branches could be created based on the staging branch and later merged back. The staging branch can be merged in the production branch when it's ready. If a bug fix is needed on the production while the developement is going on in the staging branch, we could create a hotfix branch based on the production branch, fix it and merge it back to production and the staging branch. What are the advanteges of having a main branch? What am I missing? Thank you!
If you don't have the main branch, then there is a good chance you'll find yourself rebasing from prod down to dev and piss everyone off. I will say this guys video is intriguing, but I prefer just to have a main branch for simplicity and that's it.
as an admin how can i download all users data from gitlab?
Thanks for your video! I am still learning different branching strategies for our work. However, we are facing an issue that we have concurrent developments for different features, but the feature release to production could be different. For example, feature 1 start development from 1st Jul and completed at 15th Jul, feature 2 start development from 8th Jul and completed at 20th Jul. However, feature 1 take a long time for UAT like finished at 25th Aug but feature 2 finish UAT fast at 5th Aug. In order to release the feature 2 asap, in GitLab Flow how can I release feature 2 at 15th Aug but the release does not include feature 1(because at 15th Aug feature 1 still under UAT)?
i am also curious to hear from Moss on how to handle this.
Thank for your video. I think Environment branches are suitable for SaaS that need deploy to an environment. Release branches are suitable for software that is a software simply, it don't need deploy, user will do that. If i have a release, beside, i want provide a release as a service, can i use both versions?
_" I think Environment branches are suitable for SaaS that need deploy to an environment. Release branches are suitable for software that is a software simply, it don't need deploy, user will do that."_ Yes, this is correct.
_"If i have a release, beside, i want provide a release as a service, can i use both versions?"_ I'm not sure I understand your question, could you explain a bit more?
@@tech_with_moss as Gitlab, it provides releases and also provides Gitlab services to users. So can we combine 2 versions of Gitlab flow or is there another version of Gitlab flow
@@quyetthangcao6791 If I understood your question correctly, I believe that you could combine versions of the GitLab Flow to support a hybrid workflow.
plz complete the series dont leave it in between
Could shere me git lab full course
Hello! I have actually developed a full GitLab course in collaboration with LambdaTest on their channel: th-cam.com/video/8aV5AxJrHDg/w-d-xo.html
HELP