Sprint 5:
Managing deployment, fixing problems, and implementing high priority features.
Hello, back again on the 5th Sprint. It’s the sprint where we finally managed to deploy something live and working (hooray!), albeit manually and not through our set up CI/CD.
Anyways, this sprint, I mostly work on fixing problems related to CI/CD that appear on staging and setting up flexibility to our projects. Although, it was hard to do since there was a cold fix which was supposed to fix part of the problem, yet wasn’t merged soon enough (for some reason said cold fix was managed by at least three people, and consists of lots of commits; I’m pretty sure cold fixes aren’t supposed to be that way but I was too lazy to argue), so it became something of a blocking thing.
Regardless, the testing phase works like a charm now, but the autonomous deployment phase needs more tweaking (currently, the file gitlab-ci.yml is in a messy state; need to fix it soon).
Besides that, our team as a whole is starting to focus on high priority features, since the development timeline is nearing it’s end.
Here’s another list of stuff I learned, enjoy~
Version Control with Git
Ever since the 2nd sprint, I’ve been using git a lot. Well mainly because Git is the core of our team development (via GitLab), and I’ve experienced a lot along the line.
git cherry-pick <commit-hash>I had to utilize git’s cherry-pick feature, due to my teammate merging my work into staging before it is even done. Also, for some reason my work wasn’t recorded as the commits I pushed, rather as one collective commit by a teammate of mine. The best part is, get this, my work was added into the commit by accident. It wasn’t supposed to be part of it, and I’m not sure how my teammate tested their work with mine. Along with the accidental inclusion, my ‘included’ work was slightly modified by another teammate to accommodate some requirements, a modification I was unaware of. I’m not gonna say much of what I think of this whole ordeal, but I’m pretty sure it’s clear from what I wrote.
I’ve also done local merge conflict resolving for merge conflicts that arose from my cherry-pick commits. These conflicts are from my remainder work conflicting with the modifications my teammate made. It’s a good thing that resolving merge conflicts in git is simple, and I had those conflicts resolved in no time.
git stash push
git stash popI’m also using git’s stash feature a lot, since I was jumping from developing features to fixing problems a lot. It proved to be really handy as it enables you to continue on your work almost immediately after coming from another branch.
Besides that, I used a lot of the various common git commands like commit, push, pull, etc, during the course of this project’s development.
Software Environments
I’ve talked about using Docker, but previously we didn’t have a working image for our project.
But now we do!
Most of these are manually pushed though, and the naming isn’t consistent yet. I had ppld6/back-end/staging as the image tag since forever, so I expected the front-end tag to have a similar tag. My team, however, decided it’d be ppld6/slovneek-fe (without even an indication of staging to differentiate from say, production), and so we adjusted the tag of the back-end image to match the front-end one (I had to force my teammate who’s pushing it manually to add /staging after ppld6/slovneek-be).
I’ve also somewhat grasp the concept of software environments. There are differences in things you may show when subject to a certain environment. Take, for example, the production environment. In this environment, you aren’t allowed to show any debug messages, since the production environment is the live environment, of which consumers might use.
Following that perspective, I’ve set the back-end so that the debug page will only appear on non-production environments:
For testing purposes, I had the environment in the running container at Portainer set to PRODUCTION, and here’s what it shows when an error occurs (vs. without environment set up):
Software Architecture
Currently, our software architecture looks like this:
Our software architecture follows a standard REST API style application architecture, with one layer being the presentation layer (front-end), one layer being the API layer (back-end), and one layer being the persistence layer (database). The user retrieves their UI through the presentation layer, and is displayed in their browser client.
Each of the layers has it’s own docker image, and is served in containers which are connected by networks. There’s the fe-be network which connects the front-end and the back-end (although this network might be unnecessary, since it’s entirely possible to call the back-end through the public IP address), and there’s the be-db network which connects the back-end to the database.
Originally, we had another extra service outside these three layers, namely the ElasticSearch service.
However, due to certain circumstances we had to drop ElasticSearch for the moment, and consider dropping it altogether or re-integrate it.
That’s all for this sprint. I didn’t write a lot since I’d rather allocate the time to do other assignments (nearing the end of the semester, lots of final projects combined with various assignments). Tune in next time in the final (if there ever will be) sprint blog, I’ll see you there~
