For our first sprint in the software development capstone course at Worcester State University, our team was tasked to investigate epics attached to multiple repositories within the Thea’s Pantry Gitlab page. We also needed to learn how to use Gitlab’s productivity and team management tools as we went along so we could appropriately divide up tasks among ourselves and monitor our progress. Most of our work was accomplished within the GuestInfoSystem repository and its component microsystems. We also spent time investigating the component InventorySystems in preparation for construction of test suites in the next sprint. I personally contributed to the issues attached to GuestInfoBackend, as well as contributed to sprint planning during team standup meetings and meetings outside of classroom hours.
The specific issues that our team was tasked with resolving were configuring the repositories within GuestInfoSystem for remote Gitpod development environments, renaming the ‘commands’ directory of each repository to ‘bin’ and modifying any scripts that reference the ‘commands’ directory to reflect the name change, and integrating the AlexJS linter into the Gitlab commit pipeline. After that work was finished, we would be responsible for investigating the GuestInfoSystem and InventorySystem repositories to prepare to build testing suites for the frontend and backend services during our next sprint.
Before we started work on the issues, we came together as a team to discuss how much time and effort would likely go into the completion of each task, using the weight system used by Gitlab as an estimate. The weight system is a scale from 0 to 3, with each increasing level of weight meant to represent a relative increase in time and effort necessary to resolve the issue. We attached a weight of 0 to some of our tasks while planning our sprint, which may have led us to expect that some of our work wouldn’t take as long as the task would end up requiring of us. The 0 weight in this system represents a task that shouldn’t take more than a few minutes. The only issue that we worked on this sprint that I would still argue would constitute zero weight would be the renaming of ‘commands’ to ‘bin’. Everything else required more investment of our time and concentration than we had anticipated, in part because we were still learning how to use Github’s tools to coordinate as a software development team.
Once we had agreed as a team on which weight values to assign to each of our issues, we decided to begin our sprint with preparing the repositories for development in Gitpod. Instead of cloning code from the Thea’s Pantry Gitlab page to our personal machines, we can open the repository files in a web browser based Visual Studio. This remote workspace is maintained by Gitpod for as long as we are working in it, and for 14 days of inactivity afterward. To create a workspace for the repository we want to work on, there are tools within Gitlab that allow for easy creation of a new development branch based on an issue, as well as the creation of a new Gitpod workspace based on that branch. I’ve been getting to enjoy using these remote development features, personally, and I appreciate how I can have access to all the functionality of Visual Studio without needing to install extensions on my machine.
To get each repository configured for development in Gitpod, we needed to copy the names of our desired settings from the existing ‘.devcontainer/devcontainer.json’ into ‘.vscode/settings.json’, and to copy the names of the extensions that each repository requires into ‘.gitpod.yml’, a file that can be created in the repository while working in Gitpod by using the terminal command ‘gp init’. However, we found that because of a part of the Gitlab pipeline that lints the files in the repository, we needed to change the formatting of some of the files created by that command so that no lines were longer than a certain character limit. In hindsight, I think it would have been better to try and include those files in the ignore files for the linter extensions. Ignore files are files that point to other files and directories within the repository that we don’t want the linter to review or raise any issues with. We began to recognize the utility of ignore files near the end of our sprint, but at the outset it hadn’t occurred to me to try and get around the linter errors by adding the newly created Gitpod files to an ignore list.
The issue that challenged me the most was adding the AlexJS linter to the GuestInfoBackend and to the Gitlab commit pipeline. I wasn’t anticipating that I would struggle with a task like this, because I thought I would just need to type ‘AlexJS’ into a few files and I would be done with it. While that was part of the process, I also needed to add certain files like licenses and the Code of Conduct to an ignore file. The linting process would have returned a failure status otherwise because those files contained text that would be flagged by the linter. I also spent more time I would like to admit waiting for the linting process to finish while it was iterating through the lengthy ‘node_modules’ directory. That directory needed to be added to this repository’s linter ignore files to avoid an unbearably long (and doomed to fail) linting process. I also realized by the end of the sprint that I had misunderstood the task to add AlexJS to to the Gitlab pipeline, and I had only added AlexJS to the lint shell script within the development environment. In the future I’m going to make sure I review a linter’s ignore file when newly installing it into a repository.
My most significant takeaway from this first sprint is that I shouldn’t underestimate the effort I’ll need to invest into issues that sound like they’re well within my comfort zone. We’re working as part of a cooperative effort on a complex software project, and that requires an advanced degree of communication and attention to detail. I’m not going to be able to go into tasks assuming that they will be easy just because they sound similar to problems I’ve solved before.
Gitlab issues:
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/86
- Configured GuestInfoBackend for remote Gitpod development environment
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/88#note_1785621795
- Added AlexJS linter to GuestInfoBackend shell script
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/87
- Renamed ‘commands’ to ‘bin’ and modified references to ‘commands’ in other files to reflect name change
Michael's Programming Blog 
Leave a comment