Assignment 2 - CI/CD

1. Goal

The goal of this assignment is to master the core of continuous integration and delivery. To achieve this goal, you are required to implement workflows with GitHub Actions on a new repository.

Additionally, good collaboration practices within the team should be practiced.

2. Deliverables and Presentation

Each group will create a new private GitHub repository. The URL of the repository must be submitted on Canvas, and access should be given to the organization team (vu-sep) and to the TA assigned to evaluate your work (you will find this information in the presentation spreadsheet on the presentation day). The README.md file of your project should follow the provided report template.

• Deadline: 27/06/2024

The group must present their work, during which one member should share their screen. TAs will ask questions about each group member's contribution. Be prepared to execute parts of the code as requested. By 27/06/2024, the group must sign in for a presentation slot here.

• Presentation day: 28/06/2024

In Summary:

1. Private Repository URL: Submit on Canvas.

2. Final Report (README.md): Follow the provided template.

3. Presentation: Demonstrate your work and answer questions.

3. Tasks

3.0 Repository preparation

The new private GitHub repository of your group should only contain a README.md file and a LICENSE when created. Then, the group should choose between Python and Java, and then add application and test code there. The code to be added must be from one of the following sources:

• Python

• Java

Having concluded this task, your group can start to work on the following task.

3.1 Workflows with GitHub Actions

In total, each group must create 4 workflows in their repositories:

1. Testing (testing.yml): This workflow is dedicated to compiling and testing the project each time a commit is made on the repository. Compilation and testing should be done by calling a build tool.

2. Static analysis (static_analysis_1.yml): This workflow is dedicated to executing one static analysis tool to check for code quality attributes each time a commit is made on the repository.

3. Static analysis (static_analysis_2.yml): This workflow is also dedicated to executing one static analysis tool to check for code quality attributes. The only differences between this workflow and the previous one are that i) this should be only executed when a pull request is created in the repository and ii) a different static analysis tool should be used.

4. Release (release.yml): This workflow is dedicated to creating a release on GitHub each time a commit containing the word "release" in its message is made on the main branch of the repository.

At the end of this task, your repository should have the following structure:

your_project/
├── .github/
│   └── workflows/
│       ├── testing.yml
│       ├── static_analysis_1.yml
│       ├── static_analysis_2.yml
│       └── release.yml
├── src/
├── tests/
├── LICENSE
├── README.md
└── <other files, depending on the build tools your group is using>

3.2 Collaboration

Each group member must create one of the workflows mentioned above on their own individual git branches. Once a group member has the first complete version of a workflow, they should create a pull request using that git branch (amends on the workflow can be done later through other pull requests). Then, all the other group members should review it and leave comments in the pull requests if amends are necessary (this is because all group members should learn the workflows). Eventually, one reviewer merges the pull request into the main repository branch when everybody is fine with the workflow.

All pull requests should be merged by the deadline to avoid a resit.

3.3 Report (README.md)

The README.md file in the root of your repository should document your work following the provided template (see Section 2).

4. Evaluation and Grading

Grades are collective unless discrepancies in contribution are noted. Individual participation is mandatory during the presentation.

4.1 Grading Rubrics

Criteria	Ratings	Points
1) Workflow #1.	4 Pts: There is evidence (link in the report and demonstration during the presentation) that the workflow works. 0 Pts: Otherwise.	4 pts
2) Workflow #2.	4 Pts: There is evidence (link in the report and demonstration during the presentation) that the workflow works. 0 Pts: Otherwise.	4 pts
3) Workflow #3.	4 Pts: There is evidence (link in the report and demonstration during the presentation) that the workflow works. 0 Pts: Otherwise.	4 pts
4) Workflow #4.	4 Pts: There is evidence (link in the report and demonstration during the presentation) that the workflow works and that new automated releases contain a tag and files (code archive). 3 Pts: There is evidence (link in the report and demonstration during the presentation) that the workflow works and that new automated releases contain a tag but not files (code archive). 0 Pts: Otherwise.	4 pts
5) Commit Messages.	2 Pts: All or most commit messages are clear, follow a pattern, and are traceable. 1 Pts: Some commit messages follow the criteria. 0 Pts: Commit messages are unclear, messy, or follow different patterns.	2 pts
6) Issue Tracking.	2 Pts: Issues were consistently used to organize/track the group's work. 1 Pts: Some issues were used, but inconsistently. 0 Pts: No issues were created.	2 pts
7) Pull Requests.	2 Pts: Pull requests were consistently used and reviewed before merging. 1 Pts: Some pull requests were used, but inconsistently reviewed. 0 Pts: No pull requests were created.	2 pts
8) Report (README.md).	2 Pts: The report follows the template and is clear. 1 Pts: The report is sufficient for understanding but could be improved. 0 Pts: The report is insufficient or does not follow the template.	2 pts
Total		24pts

4.2 Eligibility

To qualify for a grade, the following criteria must be met:

• More than one student per group;

• Repository URL is submitted on Canvas by the deadline;

• Registration to a presentation slot by the deadline;

• No modifications in the repository after the deadline;

• README.md contains individual contribution statements;

• All group members attend the presentation.

Checklist

1. Create Private Repository

   • Private repository created.

   • URL submitted on Canvas.

   • Access granted to the organization team (vu-sep) and TA.

   • Add a license to your repository that your team deems fit.

2. Write Workflows

   • Each member creates at least one GitHub workflow.

   • Implemented Workflow 1 (testing.yml).

   • Implemented Workflow 2 (static_analysis_1.yml).

   • Implemented Workflow 3 (static_analysis_2.yml).

   • Implemented Workflow 4 (release.yml).

3. Pull Requests and Code Review

   • Create pull request per individual branch.

   • Review and suggest changes (all group members should do it for every pull request related to workflows).

   • Merge pull requests.

4. Prepare Final Report

   • Follow the README.md template.

5. Presentation

   • Register for a presentation slot.

   • Present and be ready to execute code.

FAQ

Q: Can I work alone on the assignment?

A: No, groups should have more than one student.

Q: What if a group member cannot attend the presentation?

A: An exception must be given by the study advisor, otherwise a grade of 0 will be given and the group members will have to resit the assignment.

Q: Can we use any programming language?

A: For Assignment 2, either Python or Java must be used.

Q: How do we organize our work?

A: Use GitHub issues, pull requests, and follow good commit message practices.

Q: What happens if we don't meet the deadline?

A: Late submissions will result in a resit, and any post-deadline changes will not be considered.

Q: Our workflows are not working, what should we do?

A: Google the problem using the errors presented in the logs and the tools used in the workflows.