Getting QA Involved. Do you have a guide or process I could use to get QA involved?
I've been thinking about this ... If they could go to GitLab and "deploy" a branch to staging for testing then that would work. Each time they test - go to GitLab -> select branch -> somehow deploy to stating server On Thursday, 9 July 2020 07:15:40 UTC+10, Magnus Therning wrote: > > > SJW <shanno...@gmail.com <javascript:>> writes: > > > On Monday, 6 July 2020 22:22:49 UTC+10, Magnus Therning wrote: > >> > >> > >> SJW <shanno...@gmail.com <javascript:>> writes: > >> > >> > I am still trying to get my head around the best possible way to use > git > >> > (and failing) > >> > > >> > Here is my normal process below - but I don't like it because it is > very > >> > difficult to manage repos and versions. Hoping someone can read this > and > >> > advise me on improvements or tell me that this is just how git > works... > >> > > >> > Code bases: > >> > - DEV (local PC - this is where local git repo is configured - and > >> origin > >> > is GitLab) > >> > - STAGING (server - I have a local folder synced with server) > >> > - LIVE (server - I have a local folder synced with server) > >> > > >> > Effectively I have 3 local folders with 3 codebases (STAGING and LIVE > >> are > >> > just syncd to server) > >> > > >> > 1. I create a branch - *new-branch-1* > >> > 2. I develop new branch > >> > 3. I use WinMerge to sync DEV changes with STAGING > >> > 4. I submit changes in *new-branch-1* to QA team to review and > approve > >> > > >> > 5. I create a branch - *new-branch-2* > >> > 6. Make more changes for a separate task/project > >> > 7. I use WinMerge to sync DEV changes with STAGING > >> > > >> > *ISSUE#1*: STAGING has all changes from *new-branch-1* so there are > lots > >> of > >> > files showing that I need to manually filter through and ignore and > try > >> and > >> > find the specific changes from new-branch-2 > >> > > >> > 8. I submit changes in *new-branch-2* to QA team to review and > approve - > >> We > >> > now have both branches in STAGING > >> > > >> > 9. QA come back with some changes or improvements for *new-branch-1* > >> > 10 I checkout *new-branch-1* and update the code with the > >> recommendations > >> > from QA > >> > 11. I use WinMerge to sync DEV changes with STAGING > >> > > >> > *ISSUE#2*: Same as issue#1 now I need to manually filter out the > changes > >> > from new-branch-2 > >> > > >> > 12. Repeat with *new-branch-3* - Meanwhile, someone else has added > >> > *new-branch-4* and *new-branch-5* to staging > >> > > >> > *ISSUE#3*: Now I am trying to sync DEV and STAGING with 5 code > branches > >> - > >> > it's starting to become very difficult to identify branch specific > code > >> in > >> > STAGING > >> > > >> > 13. QA approves *new-branch-2 *- I merge *new-branch-2* back to > master > >> > 14. Compare master with LIVE and update the LIVE code with all the > >> changes > >> > > >> > It just becomes very confusing and overwhelming when you start > getting > >> lots > >> > of branches so I end up halting development and waiting for QA but > this > >> is > >> > inefficient and slows development. > >> > Does anyone have any suggestions on how I can streamline this to > avoid > >> > delays in development? > >> > >> I think you've put your finger on the issue, QA is too slow. You can do > >> manner of fixes to tools and processes, but you'll always be hindered > by > >> QA being slow! > >> > >> A few things you can try in the meantime: > >> > >> - don't use git for deploy, instead use CI/CD > >> > > > > I did try that but wasn't comfortable having git update code without > > visually seeing the changes it was making - not that comfortable or > > trustworthy yet > > Maybe we're talking past each other, but I'm saying /don't use git for > deploy/. Use `git archive` to get the latest version on a branch into a > ZIP archive (or .tar.gz, or whatever) and then use some way of deploying > the stuff in that archive. > > >> - spin up one staging for each branch you develop on > >> > > > > That seems like a lot of effort for each branch. Would probably be > > ideal but ... > > That's effort that should be automated, via your CI/CD. You check in, > then wait a few minutes and voila, you have a staging server for the > branch you pushed. Automation, automation, automation. :) > > >> In the end I think the only long-term solution is if QA is folded > >> into development, i.e. that you move the organisation to > >> cross-functional teams, including QA. > > > > Cant see it happening - there is 4 of us - 2 separate companies doing > > this as a side project - so I get 1-2 days from them per week > > Then I see two options: > > - you continue being miserable and the project limps along, or > - you find a place where you have more chance of contributing positive > change > > Just my 2ct :) > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: mag...@therning.org <javascript:> > twitter: magthe http://magnus.therning.org/ > > It is better to keep your mouth shut and appear stupid than to open it > and remove all doubt. > — Mark Twain > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/68fa2d80-8e83-4f49-86e2-8f4beffe67c8o%40googlegroups.com.
