As sprint 3 was a short cleanup sprint, we spent it doing some cleanup on the epics and issues board. During the sprint we were also trying to get a testing CI pipeline running. We ended up finally figuring that out after the technical end of the sprint, but I’ll be talking about that work here anyway.
As far as cleanup, I deleted a few remote branches in the GuestInfoBackend repo that had not been deleted when they were merged. I only deleted the branches that I knew had been merged, but now that I look at the other branches, GitLab indicates whether a branch has been merged into the main branch, so I will know which branches are clearly safe to delete this week in the backend, API, and frontend repositories.
I did some additional cleanup related to the status of features that remain in the product backlog. For example, I removed an indication that the upcoming Kubernetes conversion epic is blocked by the GuestInfoIntegration verification epic that we completed:
https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/-/epics/33
I helped Kelvin’s effort to get the GitLab test job to run our backend tests. For example, I made sure we were getting a copy of an openapi.yaml file that we knew would actually exist into the testing/test-runner/ directory while the test script is being executed:
It wound up being a bit harder than expected to get a value from bash into a YAML definition file being used to network the various docker containers. There seem to be a few more ways to do that when executing docker-run compared to docker-compose, so I figured out how to do that to get the right backend image name substituted into the docker composition for both the GitLab CI test job and when executing test.sh in a dev container:
I also verified that the test job is doing all the right docker stuff by making sure that broken unit tests and broken endpoints both result in failed tests in the test job:
I think our team did a good job getting the tests to run in the CI pipeline this sprint. At the same time, putting a bunch of energy into a different branch than main may hive divided our energy a bit. Probably more important was that this was a short sprint with lower goals than the first two. Given the fact that during sprint 1 we didn’t really know what we were doing or how most of the architecture worked together, it might have been nice to have a shorter first sprint and then more time to work on this one, where maybe half or a third of the goals were cleaning things up.
Honestly, I don’t think it’s bad that trying to gradually wrap your head around a codebase is a big part of this class, as that’s going to be one of the challenges that people face in new working environments. The software construction & architecture prerequisite class does use the same architecture, but it’s easy in that class to build better understanding of how some of the individual parts work and an understanding of microservices and REST APIs. However, the devil is in the details, and understanding small integration details enough to be confident that contributions are correct is not easy.
One other thing I wish I did differently to help our team as a whole this sprint is trying to collaborate a bit with everyone. I feel a bit like I locked myself in the test-runner branch and wasn’t very present to help with other things.
From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.