The third sprint in my capstone was a race to presenting a working project. This sprint brought new difficulties in coordinating the team and getting work done in a logical order. The issue wasn’t our team work, but rather trying to work around the pressure of getting the work done. Many issues took longer to resolve than expected, meaning we had to put a pause on some issues to help each other get prerequisite issues done.
Set up CI for Angular to automate testing and prevent failed pipeline merges
Create Angular Service to update backend
Create Docker container for Spring Boot
Create Docker container for Angular
Establish communication between all 3 docker containers (MongoDB included)
I was really happy this sprint with how our team dropped what they were doing for a team meeting. We all had snags with almost ALL of our issues, and the order in which we had planned to do things was not possible. For example, while setting up the CI, I decided to explore Docker a bit more in detail so we could potentially use the same Docker image for the CI as we used in our project. This meant that we as a team had to focus on Docker sooner than expected.
At the same time, there were some problems while working on different issues synchronously. The biggest problem came from a couple incidents of copying and pasting code from other branches to get it to work in their code, instead of waiting for the code to be merged. If someone else’s issue is blocking you from working, the team should try to resolve the issue as soon as possible first, then get the updated master branch. While copy+paste might seem easier in the short term, it has a potential to cause issues as people try to merge their own requests. For example, code was copied from one of my branches because a feature was required for another issue. These changes were then merged from a different feature branch. My merge request was never approved because the changes were already on master. When it came time to merge one of my requests, it looked like I had made no changes compared to master, because my changes had erroneously already been committed in another branch. It was especially confusing, since change had been made to my original code since then.
This could have been solved if I had blocked other issues from being merged before my issue was merged, which is a feature of GitLab. However, there were also a couple cases where certain features stopped working because code was merged to master without consulting other team members while resolving conflicts. This led to some of the work from my issues being completely erased. Luckily it was easy to add back in thanks to version control, but the extra effort could have easily been prevented. Checking the git diff more carefully while merging would help in this effort.
Branch names were also confusing in a couple cases. “Working_branch” followed by initials is not a useful name, although I understand wanting to signal to your teammates that it is your branch. Appending initials to a name describing the feature would be more useful for everyone. Even better, GitLab has options to prevent modification to a certain branch except for merge requests. You can name the branch after a feature, anyone can help you, and then you can accept changes only if you want. This makes it easier to find a branch when helping your team members with issues.
These problems did teach us about features in GitLab we were missing out on. Our team could improve by following the GitLab workflow and maintaining consistent software development processes. Deviating from this workflow hurts productivity because other members have a certain expectation on how things are being done, and for example, shouldn’t have to check to make sure a past bug fix is still on the master branch.
Despite these issues we got a lot of work done, even though it came down to finishing the night before because of all of our snags. I had a great time with this team and although we’ll no longer be working on this project on a sprint team, I’d like to continue working with any of them who will continue to contribute to this project. We’ve all learned a lot about GitLab and the technologies we’ve used and have adapted well to the new workflow.
From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.