Twisted Branches |
David pulled his headphones off when he heard a loud harrumph behind him. One of his project managers loomed in the doorway, and had obviously been standing there for some time, trying to get Davids attention.
You pulled from Staging-Core branch into the Version2 branch and broke Liams changes, the PM said.
David wracked his brain, trying to remember this particular PMs name. Hed met so many during his short time at this company that he couldnt keep them straight. Uhh… we just had a release, right? Since I was working in Version2, I pulled the latest version in. I thought I was the only one in there on this project right now…
The PM shook his head. I dont know how you did things at your old job, but here weve got policies and procedures. This isnt some tiny startup- weve got a dozen developers in this office, fifty more in India, another dozen in Mexico, and nearly a hundred testers. Ill send you a meeting invite so we can discuss…
The PM wandered off, mid-sentence, but was instantly replaced by another. This one David recognized- Lisa or Linda or Lindsey or something. Liam tells me youre breaking branches in our code control system, she said. Im not sure how things worked at your old job, but this isnt some tiny startup. Our codebase is over 1.2 million lines of code. Ill send you a meeting invite so we can discuss…
Over the next quarter of an hour, David was visited by the ghosts of project management past, present and future, each with dire comments about Davids ability to follow policy and the promise of a follow-up meeting. By mid-afternoon, his calendar for the next week was filled with meetings.
A normal organization might do work in individual feature branches and when a feature was complete, theyd migrate those changes back to the root or trunk branch for release. People working in other feature branches should, at some point, pull those changes down into those branches. When and exactly how that happened was a possible topic of debate, but Davids new workplace wasnt interested in a debate.
You simply dont pull changes down into lower branches. Ever.
David sat at a conference table, surrounded by project managers he didnt recognize.
Thats why we have a Changes Under Merge team, one of the PMs explained. Its for safety. Changes made by developers stay in one branch, and the Changes Under Merge team move them back up the tree, following the Change and Release Approach Policy.
If David needed changes synced between branches, he needed to work with the Changes Under Merge team, which was a four-person group who understood how the 20+ branches in their codebase related to each other. If, for example, David needed a feature merged in, hed need to look up all of the changesets that were used to create that feature. Hed then send them- as an Excel spreadsheet- to the Changes Under Merge team. Someone from that team would then cherry-pick just those changes and use TFSs baseless merge tool to pull those changes into his branch.
Conversely, when he had a feature ready to go, he wouldnt merge it up the tree. Hed compile a list of changesets and pass them off to the Changes Under Merge team, which would then pull the changes from his branch into Integ-Core, for integration testing by QA (there were no automated tests, because, as one of the PMs put it, Automated tests only test your automation. You need real humans for real tests.). Once the feature passed Integ-Core, the QA folks would request that the changes get merged into Strategic-CombRes, using the same cherry-pick and baseless merge approach. From there, the finished feature entered a twisty labyrinth of project management processes that David didnt need to worry about. His feature would hop around the various Strategic Branches for awhile, and someday, maybe, make it back up into the Production branch.
David took his scoldings, did his best not to roll his eyes, and got back to work when the project management machine decided that hed been punished enough. For the next six months, he basically ignored everything he knew about branches, and just rigorously tracked his changesets so that he could pass them off to the Changes Under Merge team. Eventually, he started to hear whispers- a major release was coming, and everyoned need to put in some extra time to make sure it went off without a hitch.
Lisa/Linda/Lindsey descended on his cube on the eve of the release. Now, since this is your first major milestone, she said, I wanted to stop by and review whats going to happen. Youre going to get a list of changesets from the Changes Under Merge team. You need to look at the latest version of the Production branch and verify that all of your changes are in there. And no, you cant just look and see if the changeset IDs are in there, because sometimes changes get overwritten by later changes. Youll need to manually verify every line youve written. Youve got two hours.
This was six months worth of work. David didnt even know where to begin with verifying every line hed written. And in only two hours? It was impossible. Instead, he focused on spot-checking the release while wishing hed been allowed to write some automated tests around his features. So far as he could tell, everything looked okay, so he signed off on the release.
The release crashed and burned. Since the company didnt have a backout plan, and since their branching structure was convoluted, they couldnt simply pull the previous version out of source control and redeploy it. Instead, every developer pulled the latest version of the Production branch and worked until 2AM trying to patch all of the problems in it.
There were a lot, and when the blamestorming session finally came around, several project managers were pointing their fingers at him. You said all of your changes were in the final product, but it looks like Liams changes overwrote some of your changes. We need people that are going to follow policy. We need people who show real diligence. We dont think this organization is the right fit for you.
It wasnt until he was 45 minutes into the meeting that David realized he was being fired. He wasnt entirely certain that all of the PMs realized it either, because a few of them kept the meeting running. Obviously, one of them said, while David was at fault, this problem is also a management problem. We need to expand the management team so that we can avoid these problems in the future. And since our headcount just shrank…
| Комментировать | « Пред. запись — К дневнику — След. запись » | Страницы: [1] [Новые] |