DEVOPS DOCUMENTATION
The DevOps practice, integrating development and operations, revolutionizes the software development lifecycle. This project incorporated fundamental DevOps principles to optimize efficiency and quality. We will delve into each aspect in-depth, from task control to automated deployment, highlighting tool choices and adopted strategies.
JetBrains' YouTrack emerged as a robust choice for task and requirement control. The tool facilitated an agile approach, making it easy to create, assign, and trace tasks. Each task represented a specific requirement, providing a detailed view of project progress and dependencies. The continuous integration between YouTrack and the version control system established a cohesive environment for development.
To create a new task, you must click on the + symbol in the backlog column and fill in the task information, such as the title, description, the requirement it belongs to and other necessary information
Task control followed an agile methodology with short iterations and constant user feedback. Regular meetings occurred at each stage of the lifecycle to ensure tasks aligned with customer expectations. Close collaboration between the development team and the customer was essential for continuous adjustments and keeping the project customer-centric.
The integration between YouTrack and the version control system extended to ensure clear traceability between commits and requirements. Each commit was associated with a specific task, providing a granular view of implemented changes concerning project requirements. This traceability was valuable for audits, impact analysis, and understanding code evolution in response to customer requirements.
Branch management adopted the Gitflow strategy, a robust approach to organizing the workflow. The structure involved maintaining main branches like master and develop, along with feature and bugfix branches. Each feature or fix was developed in a specific branch, isolating it from the main code until completion. The strategy provided an organized development environment and facilitated code review and change incorporation.
To create new branches, you must go to your project's terminal and, from your project's developer branch, create a branch of it by typing the command:
"git checkout -b "branch type/code task"
For example
"git checkout -b "feature/CCC-0100"
This way, all changes made will be in your new branch
To commit your changes you must first add the files you created using the command
git add .
After that, you will commit your changes locally using the command
git commit -m "CODE TASK - Description of the task performed"
After committing your changes locally, you can commit your branch remotely using the command
git push
After uploading your branch, you can open a pull request to merge your changes into the developer branch. To open a pull request, go to your project's github repository and click on "Pull Requests" and "New pull request"
After that, select the developer branch as a base, and your feature branch to be compared
After this procedure, create your pull request and wait for someone's approval to analyze and merge your changes into the developer branch
Branch management included a rigorous code review practice. Before merging a feature or fix, a mandatory review process involving peer code review was required. This practice not only ensured code quality but also facilitated knowledge dissemination within the team. Constructive comments and discussions during reviews contributed to a culture of continuous improvement.
The Gitflow strategy, with its clear branch segregation, minimized conflicts during simultaneous feature development by different team members. Continuous integration was implemented in tandem, ensuring each feature was tested and validated before merging into the develop branch. This ensured the main code remained stable and ready for new implementations.
Continuous Integration (CI) was incorporated into the project through the GitHub Actions platform. With each push or pull request, a CI pipeline was triggered, consisting of several crucial steps. This included code compilation, execution of unit tests, static code analysis, and code coverage evaluation using Jacoco. The use of parallel jobs optimized the efficiency of the process and ensured quick issue identification.
CI configuration files are contained within the .github/workflows folder of the project repository
By detailing the job process you can have access to the processes that the actions execute and whether they occurred correctly or had failures
Continuous Integration was not just a practice but a strict policy. The policy stated that no code could be merged without passing all CI pipeline checks. This ensured that only tested and validated code was incorporated into the main codebase, maintaining repository integrity and preventing regressions.
The use of CI provided immediate feedback to developers. By identifying test failures or code pattern violations, the pipeline issued instant alerts. This practice accelerated issue identification and correction, allowing for rapid iterations and an agile development cycle.
Quality assurance was intrinsic to the testing practice, and JUnit emerged as the primary framework for unit testing. Each system component was accompanied by rigorous unit tests, covering both positive and negative scenarios. The testing approach was driven by use cases, ensuring essential functionalities were validated.
To create a new test, you must create a new class in the project's tests folder. This class must contain the name of the class you will test, ending with the name "test" at the end
Jacoco was incorporated for code coverage assessment. This critical component provided a holistic view of which parts of the code were exercised by the tests. Detailed coverage analysis allowed for identifying test gaps and directing efforts towards higher-risk areas.
To run the Jacoco, you need to type this code on terminal
mvn test jacoco:report
To see your code coverage, you must access the target/site/index.html folder. In this file there will be an html containing the coverage levels of your code
The testing practice extended beyond feature development. Continuous tests were conducted as part of continuous integration, ensuring new implementations didn't introduce regressions and that the system's integrity was maintained.
The deployment process, often prone to human errors, was fully automated through GitHub Actions. After a pull request approval and merge into the master branch, a deployment pipeline was triggered. This pipeline packaged the application, transferred it to the production server via SFTP, and executed specific startup and update procedures.
The code that contains the job configuration for deployment is contained within the maven.yaml file within the .github/workflows folder within the project
A gradual deployment strategy was adopted to mitigate risks. Instead of an instant update, the deployment process involved controlled steps. The new code was validated for stability, and then progressively implemented in production environments. This allowed for quick rollback in case of issues and ensured a seamless experience for end-users.
Documentation, often underestimated, played a crucial role in the project. GitHub Wiki was chosen as the central repository for documentation, covering everything from project overview to technical details. Topics such as architecture, deployment processes, and best practices were meticulously documented.
The backend API was thoroughly documented using Swagger. This provided an interactive interface to explore endpoints, input parameters, and expected outputs. Swagger not only simplified developer understanding of the API but also facilitated integration with other parts of the system.
The application swagger address is available at http://168.138.135.134:8081/swagger-ui/index.html#/
Each aspect addressed in this project was not just an isolated practice but an integral piece of a continuous improvement cycle. Task control fed into branch management, which in turn influenced continuous integration. Testing and deployment were intertwined, ensuring only reliable code was deployed.
The DevOps cycle is not static; it is fueled by continuous feedback. Code review practices provided valuable insights into code quality. Test reports and code coverage metrics guided additional improvements. This holistic DevOps approach not only accelerated the development cycle but also established an environment conducive to innovation and resilience.