Project Management using GitFlow

The purpose of this practice is to work with the GitFlow model developed by Vincent Driessen in 2010, providing our application with a framework for branch and version management, aiding in maintaining an organized and efficient structure. It enables development teams to work more collaboratively and help us to ensure the construction of high-quality software. As we progressed with the project, we explored various workflows and incorporated additional functionalities, including the implementation of new features in the sample app. This involved creating essential branches and subjecting our changes to rigorous validation processes to ensure seamless integration with the rest of the project. Furthermore, we adopted the GitFlow model to align our development practices with the day-to-day operations of the business.

ISSUES

You can click here to access to our repo of GitHub. Also, in this link you can find our Okteto deployment (currently sleeping!). Any issue can be reported here including as header "PROJECTMANAGEMENT ISSUE" and I will try to solve it as soon as posible!

PHASE 1 - WORKFLOWS

[May 3, 2023]

Workflow 1 - Unitary and Integration Testing

We have created the first workflow in the .github/workflows folder, which handles the functionality of running unit and integration tests when we fetch a branch with the "feature" pattern and merge it with the "develop" branch. To achieve this, we have created these branches using both the GitHub website and the following command:

$ git branch

This allows us to create new branches locally for deployment purposes. Additionally, we have used basic commands to upload files:

$ git add .
$ git commit -m "msg"
$ git push -u origin "branch"

Workflow 2 - Commit Testing

We have created the second workflow in the develop branch, as it was required to run the entire application test suite whenever a git push is made to this branch. Additionally, we have used basic git commands to create and upload files:

$ git add .
$ git commit -m "msg"
$ git push -u origin "branch"

Highlighting the test git push performed to verify that the workflow functions correctly. It is worth mentioning that both workflows, as well as future workflows, have been configured to generate artifacts that store the temporary results of these workflows and, therefore, the test results. This allows us to easily access the artifact in case a workflow fails, helping us identify and troubleshoot any errors.

[May 4, 2023]

Workflow 3 - Nightly Testing

Creating the third workflow required some effort to structure it properly, but we managed to accomplish it. Similar to workflow 2, we have separated the tasks independently and categorized them as requested, such as e2e, rest, etc. Additionally, we have created a Docker image (once all the tests have passed successfully) using the following command:

# Creation of the docker image
$ mvn spring-boot:build-image -DskipTests -Dspring-boot.build-image.imageName=${{ secrets.DOCKERHUB_USERNAME }}/image_name
# Log in to Docker
$ docker login --username="${{ secrets.DOCKERHUB_USERNAME }}" --password="${{ secrets.DOCKERHUB_TOKEN }}" 
# Push the image
$ docker push "${{ secrets.DOCKERHUB_USERNAME }}"/books-reviewer:dev-$(date +%Y%m%d) 
# Log out
$ docker logout 

We are still waiting for the "schedule: crono" part to work. We have tried changing it to a push event to test if our workflow was incorrect, and it worked fine. Therefore, we have scheduled the workflow to run in a few hours to test and see what happens. We have used the same structure as provided in the slides, but without success.

Workflow 4 - Release Testing

The fourth workflow consists of running unit and integration tests in the test branch release/workflow4-test. This process occurs automatically every time a new commit is detected in that branch. Once again, we have executed the tasks independently, starting with the integration tests and then the unit tests. The results for both tests are stored in artifacts named integ-results.txt and unit-results.txt respectively.

[May 5, 2023]

Workflow 5 - Deployment Testing

The fifth workflow consists of the final workflow, which involves merging a stable release version from the develop branch into the production branch master. We needed to specify the source as develop as required in the prompt, using a brief bash script, as well as the need to install the Okteto CLI:

- name: Verifying source branch
        run: |
             if [[ "${{ github.event.pull_request.head.ref }}" != "develop" ]]; then
              echo "The pull request source branch is not 'develop'. Exiting."
              exit 1
             fi
- name: Installing Okteto CLI
  run: |
    curl https://get.okteto.com -sSfL | sh

Posteriormente ejecutamos todas las pruebas, construimos la imagen de Docker y la subimos a DocherHub, de la misma forma que hacíamos en el workflow 3, con la diferencia de que ahora utilizando los siguientes comandos:

$ okteto context use https://cloud.okteto.com --token ${{ secrets.OKTETO_TOKEN }}
$ okteto deploy --wait --build

We are able to deploy the Docker image to an Okteto container, providing portability through a URL. Additionally, for the successful deployment on Okteto, we had to configure the docker-compose.yml file, which specifies the books-reviewer service as the Docker image to be uploaded to Okteto. We encountered various issues when running the workflow, especially related to Okteto. We would have liked to automate the image specified in the docker-compose.yml file, as no matter how much we specified the Docker username as a GitHub secret in the image attribute, as well as the version through the command line using the following command:

# Command used in various cases for obtaining the POM version
$(mvn org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.version -q -DforceStdout)

It is not possible as we have seen that it is not supported. Furthermore, we reviewed the GitHub documentation and attempted to automate the process using:

# Trying to specify it directly
image: ${{ secrets.DOCKERHUB_USERNAME }}/books-reviewer:$(mvn org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.version -q -DforceStdout)
# Another try using environment
environment:
  VERSION: $(mvn org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.version -q -DforceStdout)
  DOCKERUSERNAME: ${{ secrets.DOCKERHUB_USERNAME }}
image: ${DOCKERUSERNAME}/books-reviewer:${VERSION}

However, we were unable to make it work, so we had to write the image directly:

version: '3'

services:
  books-reviewer:
    image: gu4re/books-reviewer:0.2.0-SNAPSHOT # Type it literally due to environment problems
    ports:
      - 8080:8080

RELEASE Workflow 3 - Nightly Testing

After many attempts and consulting the GitHub documentation and StackOverflow, we discovered that for the schedule to work correctly, the workflow needs to be on the master branch. Therefore, we copied the workflow we had developed on the develop branch to the master branch, achieving a successful test run at the scheduled time (0:30 UTC, 2:30 in Spain). The Docker image generated from that DockerHub execution can be found here.

PHASE 2 - Developing with (GitFlow/TBD)

Once the workflows were created and functioning properly, we proceeded to develop the new functionality using (GitFlow or TBD).

# Clone to a local repo
$ git clone https://github.com/Laara2705/ais-l.fernandezgu.2020-d.picazo.2020-2023.git Practica3-AIS
# Using IntelliJ
$ cd Practica3-AIS
$ idea .

We have determined that the best approach would be to include this new functionality within the BookDetail class, specifically within the setDescription(String description) method, which defines the description of a book. We have implemented it as follows:

// In this way, when a description exceeds the limit, we keep the first 947 characters.
// fill the remaining 3 characters up to 950 with '...'                                          
public void setDescription(String description) {
        if (description.length() > MAX_DESCRIPTION_LENGTH)
            this.description = description.substring(0, MAX_DESCRIPTION_LENGTH - 3)
                    .concat("...");
        else
            this.description = description;
    }

Then we added the changes to the remote repository in the following way:

$ git add .
$ git commit -m "Added the new feature"
$ git push -u origin feature/short-description

Later, we generated a pull request to merge the branch that contains the new functionality feature/short-description into the development branch develop. This action triggered a workflow that successfully validated the action. We merged the branches and integrated the changes into the development branch develop. However, when we merged the branches, another commit workflow was triggered in the development branch develop. Upon careful observation, we noticed that although the workflow passed successfully, in the resulting artifacts, specifically in the Unitary Test Results, a minor error occurred in one of the tests, specifically in the testEXTRA, which was one of the tests we programmed in the initial practice. Nevertheless, the workflow passed successfully as the flow itself did not consider it a critical error and did not affect the normal behavior of the application. However, following the GitFlow model, we will now create a branch called hotfix/short-description and apply a hotfix or fix for this minor error to resolve the issue before releasing, thus providing greater stability to the production version we want to release. Finally, we applied a small hotfix to our testEXTRA, which was a unit test, and managed to solve the problem. We simply needed to avoid the NullPointerException that occurred when we did not provide a test description when generating a Book within the test, resolving it in the following way:

@Test
@DisplayName("EXTRA: Checking good ID-book passed")
// EXTRA test checking what happens if a good ID is passed
public void testUNIT_EXTRA(){
      /* Given */
      Optional<BookDetail> bookDetailGood;
      // random valid id of an existing book
      when(openLibraryService.getBook("OL259010W"))
                  .thenReturn(
                              new OpenLibraryService.BookData(null, "/work/01",
                              // hello-world is now the new description
                              "hello-world", new Integer[1], new String[]{"HELLO WORLD"}));
      bookDetailGood = bookService.findById("OL259010W");
      Assertions.assertNotSame(Optional.empty(), bookDetailGood,
                  "bookDetail should not be empty");
}

BOOKS REVIEWER v0.2.0

After merging the hotfix branch into the develop branch, just as it happened previously with the feature, two workflows were generated. This time, both workflows passed successfully. One workflow was triggered by the pull request and merge into the development branch (pull request workflow), and the other workflow was triggered by pushing and committing to the development branch (push and commit workflow). Both workflows included the hotfix. To almost complete the GitFlow process, we are going to make some corrections in the POM file (specify our names in the artifactID) and refine the docker-compose file. Then, we will deploy a stable release of our application from the develop branch with the name release/0.2.0. Finally, we uncommented the Generating Selenium Artifact part in all the workflows (previously commented due to the limitation of the free plan for artifact storage), and adjusted the version of our application in the POM file and the docker-compose file. We have verified that we do not have any issues with the release thanks to the executed workflow. Therefore, we are going to merge the release with the development branch develop by opening a pull request, and respecting those workflows that will be executed before carrying out this process. We have just added the new release v0.2.0 to the development branch develop, which triggered two workflows: one from the pull request (pull request workflow) and another from pushing and committing to the development branch (push and commit workflow). Finally, we will deploy the application to the production branch master and make some final commits to fine-tune and prepare it for possible future development of version v0.3.0. Lastly, we have integrated the application into the production branch. Here are some final links where you can obtain the artifacts and final images of the application:

Deploying Books Reviewer v0.2.0 in master Deployment into Okteto Docker Image v0.2.0 ARTIFACT: Docker Push Results

ARTIFACT: Integration Testing Results ARTIFACT: REST Testing Results ARTIFACT: Selenium Testing Results ARTIFACT: Unitary Testing Results