Lab 5 Report (12.03.2026) - bounswe/bounswe2026group11 GitHub Wiki
Lab 5 Report
Introduction
This report summarizes the activities carried out during Lab 5 of the CmpE 354 Software Engineering course. The objective of this lab was to practice collaborative development using GitHub workflows, integrate public APIs into a provided stub application, and containerize the application using Docker. Each team member implemented a small feature within the stub application, submitted their work through pull requests, and merged their contributions following the team's development conventions.
Stub App Completion
All team members completed their own stub app tasks, including the required button implementation, Dockerfile preparation, and merging their work into the feature/stub-app branch.
Planning Situation
At the beginning of the term, we organized our team by dividing responsibilities into sub-teams so that development could proceed in a more structured and manageable way. We determined the main areas of work as backend/infrastructure, mobile, and frontend, and assigned members accordingly.
This planning helped us clarify responsibilities early, select our technology stack, and establish a foundation for both the MVP and the final milestone.
Conventions
To ensure a consistent and maintainable development workflow, our team follows several conventions related to GitHub usage, commit messages, branching strategies, and pull request policies. These conventions help maintain code quality, enable easier collaboration, and make the development history easier to understand and review.
Commit Naming Convention
We follow the Conventional Commits format for commit messages:
type(optional scope): description
This format ensures that commit history remains readable and structured. It also helps team members quickly understand the purpose of each commit.
Examples:
feat: add location search functionality
fix: resolve API response parsing issue
docs: update project wiki
refactor: improve map component structure
Common commit types used in our project include:
| Type | Description |
|---|---|
| feat | introducing a new feature |
| fix | bug fixes |
| docs | documentation updates |
| test | adding or updating tests |
| refactor | restructuring code without changing functionality |
| chore | maintenance tasks |
| ci | continuous integration related changes |
| build | build system changes |
| perf | performance improvements |
Using this standardized structure ensures that the commit history is meaningful and easier to review.
Branching Strategy
We use a structured branch naming convention based on the type of work being performed. This allows the team to clearly identify the purpose of each branch and reduces confusion during development.
Examples:
feature/location-search
feature/map-integration
bugfix/api-error
docs/wiki-update
refactor/code-cleanup
Branch prefixes used in the project:
| Prefix | Purpose |
|---|---|
| feature | development of new features |
| bugfix | fixing bugs |
| docs | documentation changes |
| refactor | code restructuring |
Each team member creates their own working branch for a specific task and opens a pull request after completing the implementation.
Merge Policy
Before opening a pull request, the following conditions must be satisfied:
- the code must run successfully on the developer's local environment
- the changes must follow the project's coding and commit conventions
- the branch must include the latest updates from the base branch
Each pull request must be reviewed and approved by at least one other team member before it is merged. This review process helps detect potential issues early and ensures better code quality.
Team members review one another’s work throughout the development process.
Branch Update Rule
Before opening a pull request, the working branch must be synchronized with the latest version of its base branch. This prevents merge conflicts and ensures compatibility with the most recent changes in the repository.
Developers update their branches using commands such as:
git pull origin feature/stub-app
or
git rebase feature/stub-app
This rule helps maintain a clean and organized Git history.
Team Structure and Roles
- Team Structure Chosen: Option A – Specialized Sub-Teams
Our team adopted Option A, where members are organized into specialized sub-teams. In our project, these sub-teams are Backend / Infrastructure, Frontend / Web, and Mobile.
- The Backend / Infrastructure team is responsible for backend development, database-related tasks, and deployment/infrastructure work.
- The Frontend / Web team is responsible for the web interface and user-facing components.
- The Mobile team is responsible for the mobile application and its integration with the backend services.
| Backend / Infrastructure | Frontend / Web | Mobile |
|---|---|---|
| Utku Yiğit Demir | Oğuz Özer | Cansu Er |
| Mehmet Kaan Ünsel | Emine Türk | Buğra Keser |
| Mehmet Akif Yıldırım | Sevde Pekköse |
Implementation Plan
Individual Contributions
Utku Yiğit Demir
- Created the Lab Report 5 Page
- Implemented Button 8 to navigate users to a new page that fetches a random dog image from the Dog CEO API and provides a brief description of the displayed data. #100
Cansu Er
- Collectively worked on adding the provided stub app content to a new branch.
- Implemented Button 4 to navigate users to a new page that fetches a Chuck Norris API response and provides a brief description of the displayed data. #98
Buğra Keser
- Created a single branch called 'feature/stub-app'
- Individually implemented button 5 with random dog photos from a public api. #93
Oğuz Özer
*Implemented Button 2 in the stub application, added a new page with button2.html integration, prepared a simple Dockerfile, and submitted the work through a pull request
Sevde Pekköse
- Implemented Button 6 in the stub application, added a new page with Cat Fact API integration, prepared a simple Dockerfile, and submitted the work through a pull request #95.
Emine Türk
*Implemented Button 7 in the stub application, added a new page with emine-button.html integration, prepared a simple Dockerfile, and submitted the work through a pull request #112.
Mehmet Kaan Ünsel
Implemented Button 1 in the stub application, added a new page with github-events.html integration, prepared a simple Dockerfile, and submitted the work through a pull request #91
Mehmet Akif Yıldırım
Implemented Button 3 in the stub application, added a new page (locations.html) with OpenStreetMap Nominatim API integration for location search, separated JavaScript into a standalone locations.js file, prepared a simple Dockerfile using nginx, and submitted the work through a pull request #92