Gitlab Repository - How should be arranged

This lesson shows you the way in which your group repository should be organized for the Mobile App Development course.

Your repo is a extension of you. So, treat it like it is something important. Keep it up to date and please follow the guidelines that we will give you.

When each member of your team has its own GitLab user, choose one of your mates to be the one who creates the GitLab group and make him/her follow the next steps.

Creating a Group

When you log into GitLab you will be redirected to your projects page. Here, click in the groups tab. Once there, click on "Your groups" option

Here, you will create a group for all of your teammates. You just have to do this one time per group. Please do not create a group for each of your teammates.

A group is like a filesystem folder, but for repositories. It is where you will create all the team repos.

The group path has to be ISIS3510_202Yxx_TeamN, where Y is the year, xx the semestrer (10 for the first semester and 20 for the second semester of the year), and N is the number of your team. The group name should be the same. It has to include in the description, the name of all the members of the group, with their respective emails and the link to their personal repository (name - email - link). Set the visibility level to public for the moment.

This is an example for the first semester of 2020:

Creating Repositories

Then, click on new project to create a repository. You have to create 3 projects. One for each code project (remember that you have to choose two platforms from the three proposed for this course: Android [Java/Kotlin], Flutter and iOS) and one that will be your wiki (where your team will upload future documents and also keep and update the product backlog).

The repositories have to be named properly. Each one with the name of the project that would be stored inside. If your team is going to work with Flutter and Android Kotlin, the repositories should be called like you see in the following image:

Adding Members to the Group

Go to the Members section in the left bar. In there, write in the search bar the username of your teammates, and add them to the group. Don't forget to add our user: se4ma.uniandes.

Wiki Repository

Go to the 'Wiki' project and create a 'Home' page which has to include in the description, the name of all the members of the group, with their respective emails, the link to their personal repository (name - email - link) and the problems you chose to solve. Also, upload the team contract to the wiki.

Finally, create a Table of Content in which you should organize all the deliverables by Sprint:

Each Sprint must have a subdirectory (SprintX where X is the number of the sprint) and inside of it, there should be a page for each micro sprint (MSY where Y is the number of the micro sprint) as follows:

Important: If the deliverable isn't correctly named nor inside the corresponding subdirectory, it won't be graded.

Further reading: Defining Milestones and Issues

Now that you have the team repositories, it is important to define the functionalities that would be implemented in the apps. To do that, go to the WIKI repository. In there, select issues at the left bar and then select milestones.

Create one milestone for this Sprint, select the start and the due date.

Then, go to labels, clicking on the left bar. And create labels that would be assign to the functionalities that will be created next. For instance, you should create labels like Android, iOS, Backend, Web, Analytics, Test, Design. Each one of the labels should have a different color and a description.

After creating all the labels, go to List, in the left bar. Here you can create issues. Create all the issues and remember to assign, a person in charge of the issue, a milestone, the labels related to the issue and a due date.

After you have create all the issues go to Board in the left bar. Once there, select "Add default lists" to add the "To Do" and "Doing" lists.

With this, you can use the lists to keep a visual state of your development. When you are going to start working in one issue move the issue to the Doing list, and when you finish doing the issue move it to the closed list.