All,
Today the primary developers and managers of the Rails 4 upgrade met to do
a retrospective of the upgrade project. This is a summary of what was
discussed during the meeting. The intent is to cover the highlights,
recurring topics, and ideas for improvement. If there is anything missing
please feel free to make additions. Feedback is definitely welcome.
Overall the team felt the project went well but that we could or should
have finished sooner. We missed the dev complete deadline by a few days.
The timeline for the project was difficult to establish given there were
several unknowns. Progress and current status was also vague at times. The
objectives of the project and a definition of done was not established at
the beginning which resulted in a bit of last minute scrambling to complete
additional tasks. Despite all this we did manage to merge the code, get
nightly builds, and ensure compatibility of several core plugins relatively
quickly near the end. This had a lot to do with the additional support we
received from others outside of the core team. We greatly appreciate this
help and want to thank everyone that contributed!
Communication was mentioned several times during the meeting. The general
opinion seemed to be that the teams felt disconnected. Foreman was doing an
upgrade; Katello was doing an upgrade. This resulted in frustration at
times when decisions or changes were made and not communicated. Not all
decisions were a collaboration. This lack of communication also made it
difficult to keep efforts in sync and we occasionally made changes that
would break one app or the other. Throughout the project we synced weekly,
but felt that more frequent syncs would have improved collaboration.
Process wise we had some issues. The usage of git and branching strategy
differed from our established practice. We relied on private branches for
several of the apps; some of which had their history rewritten throughout
the upgrade. There were a couple regressions when merging the latest
develop or master branches back into the upgrade branches; though this was
not always avoidable. We also didn’t establish a jenkins test job early in
the project that would have been helpful to catch regressions. There was
also a difference in the strategy between the two teams. The foreman team
worked to bring as many backwards compatible changes into the develop
branch; resulting in a smaller diff and less rework on every merge of
develop back into the upgrade branch. The katello team focused heavily on
fixing test failures and making known upgrade changes to the code base;
less on backwards compatibility in master. This resulted in more work
during every merge of master into the upgrade branch. The consensus was
that moving as many backwards compatible changes as possible into the
mainline branch was the better strategy.
We discussed many ideas to improve.
-
Establish a definition of done and clear objectives from the start.
-
Utilize a tool such as trello to track the upgrade progress. This would
provide us with a clearer understanding of the project status and velocity.
Having some metrics regarding velocity would help when establishing an
expected delivery date. -
Sync more frequently. Possibly provide status updates daily to keep
everyone up to date on the project status. -
Avoid private branches and don’t rewrite history of shared branches.
-
Automated testing from the start.
-
Work with a common strategy.
Hopefully I’ve captured everyone’s thoughts and opinions objectively.
Thanks,
Chris