And I should remind everyone that Mainline Integration is more than just merging the current mainline into the feature branch
I think this is an area, while technically correct, is something to seek the majority of the time. However I don't see a benefit to push unfinished work to a shared mainline.
When I have created a merge request, I find many times after I use it for a bit that I did not get something. And I know that even before I get to a merge request I will work through a number of important items. I can't imagine trying to meet a once a day integration over getting clarity on the work I'm doing.
As QA I do have the benefit that I'm also the user of the code I write. ButI'm still building infrastructure, changing architecture, and trying to break apart the pieces I believe to be complete from those that still needs work.
Andrew Cahill is a software developer/architect/CTO writing software since 2002 & professionally since 2009. Working in startups to fortune 100 companies in Europe, the US and the Middle East.
Hi Jesse,
Thanks for your comment. I fully understand the concerns on this and I had the same concerns due to potentially causing more pain & headache due to the extra effort in co-ordinating finished vs unfinished work.
However, my thoughts around this are not necessarily a right vs wrong scenario rather an ideal to work toward and put in place the necessary processes to allow for unfinished work to be committed such as feature flags etc.
This will allow you to commit not only unfinished work but to your point work you may soon later realize there is a different perhaps preferable approach and update this code ahead of going live.
Yes, there will be issues committing unfinished work if safeguards are not in place however I don’t think this is a reason not to do this as there are definitely advantages of committing with this frequency. So, I think the path is if this is not possible right now - fine however working towards this over time will ultimately yield superior agility.
I would almost compare this to DevOps - there are upfront costs associated with putting in such processes and infrastructure but you believe will pay off afterwards.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fowler says:
I think this is an area, while technically correct, is something to seek the majority of the time. However I don't see a benefit to push unfinished work to a shared mainline.
Importance of Pull Requests for Skilled Programmer
Jesse Phillips ・ Jan 6 ・ 4 min read
When I have created a merge request, I find many times after I use it for a bit that I did not get something. And I know that even before I get to a merge request I will work through a number of important items. I can't imagine trying to meet a once a day integration over getting clarity on the work I'm doing.
As QA I do have the benefit that I'm also the user of the code I write. ButI'm still building infrastructure, changing architecture, and trying to break apart the pieces I believe to be complete from those that still needs work.
Hi Jesse,
Thanks for your comment. I fully understand the concerns on this and I had the same concerns due to potentially causing more pain & headache due to the extra effort in co-ordinating finished vs unfinished work.
However, my thoughts around this are not necessarily a right vs wrong scenario rather an ideal to work toward and put in place the necessary processes to allow for unfinished work to be committed such as feature flags etc.
This will allow you to commit not only unfinished work but to your point work you may soon later realize there is a different perhaps preferable approach and update this code ahead of going live.
Yes, there will be issues committing unfinished work if safeguards are not in place however I don’t think this is a reason not to do this as there are definitely advantages of committing with this frequency. So, I think the path is if this is not possible right now - fine however working towards this over time will ultimately yield superior agility.
I would almost compare this to DevOps - there are upfront costs associated with putting in such processes and infrastructure but you believe will pay off afterwards.