Warning : In this file we only express the life cycle and the way of maintaining our app for the DevOps project. To learn about what it actually does please refer to the README.md at the root of this project. Also for the moment the pipeline runs only as if Linux was the only available target.
Formal
- Hand in a deep link to the file(s) located in that repository
Content
Life Cycle of the Application
The application we want to maintain has to be handled following the DevOps concepts learnt during lectures and exercices.
The life cycle of this app is handled through many tools and methods that we develop in this description.
-
Development
We want the maintaining of the application to be as easier as possible for both developers, deployers and users. Knowing this we need to apply as much automation as possible in the maintaining process.
Obviously the developers needs to respect the Contributing guidelines provided by the original authors in doc/developer.rst to make the automation possible and smooth. For example, frequent and light commits are needed in order to make debugging easier and, in turn, also make patching easier.
The project remote repository is hosted on GitLab.com as a public project.
-
CI/CD : Continuous Integration
The Continuous Integration part is handled with our GitLab.com. The CI pipeline defined by the .gitlab-ci.yml file is triggered automatically through local commit. It means that every time you commit as a developer to your local working tree, the GitLab CI pipeline runs every stages and all the jobs they contain in a pre-defined order to build, test (at different granularity) and deploy your commit.
I chose GitLab.com as the automation platform to be able to respect the configuration-as-code easily. This way the pipeline definition is right next to the source code of the application it is maintaining.
-
CI/CD : Continuous Delivery
If all CI jobs pass it's time for the CD pipeline to run. This Continous Delivery pipeline is meant to check for the deployability of the uploaded new code on a frequent basis. It ensures that we can safely deploy the application integrating this code while keeping stability. It allows to be ready anytime to deploy.
-
CI/CD : Continuous Deployment
This last CI/CD stage is the less automated one. But it still contains automated steps such as deep tests of the application on every release. It will be triggered manually and if the previous pipeline runned on the last delivered version is a success it allows to generate for example installers and to publish the code. This also integrated users feedback which is only availbale at this point. The more frequent and light we keep the changes between 2 deliveries, the more the user feedback will be quickly debugged and patched.
We still need to define what tool we'll use for deployment purpose.
-
CI/CD : Failed pipelines and feedback Every failed pipeline needs to be tracked. The jobs logs are saved to a distant file which is accessible through the pipeline handler on GitLab.com with developers rights on the project. The GitLab platform also permit us to receive mail notifications when pipelines fail.
The users feedback needs also to be archived and we allow using a mail bug reporting service for notification purpose and all the user feedback also need to be stored and developer-accessible on the cloud.
We chose the mail to be noticed as soon as something is reported by users.
Infrastructure Architecture and Provisioning
-
Cloud
We need to have a cloud provider and for this purpose we chose to work with AWS because it's the one I'm the most familiar with as soon as I used it previously during an internship. Also it provides a lot of documentation and user experience on many forums which we can use in case of difficulties. The bad point about AWS is that it is not free to use so maybe we would have use something else for personal purpose but the school is providing us ressources to use it.
-
IaC
-
Containerization
In one hand, for containers and container images purpose, the service we'll use is Docker for flexibility between building and running purposes.
In the other hand, for virtualization purpose, we use Virtual Box for its user friendly usage but also because I used it many times before as I often needed Linux hotsed machine but my personal computer's OS is win10. Finally it's the one that was used during the lectures for demonstration.
Outline the architecture of your infrastructure and how it will be provisioned. This should include:
- High-level overview of infrastructure components (e.g., load balancers, VMs, containers)
- Description of how each component is provisioned, whether manually or automatically (e.g., using Infrastructure as Code tools like Terraform or CloudFormation)
Decision Explanation
Explain the decisions you made throughout the project, focusing on the rationale behind your choices. Include:
- Why certain technologies or frameworks were chosen over others
- Trade-offs made between cost, performance, scalability, and maintainability
- The benefits and challenges of the selected technology stack
Technology Stack
-
Programming language
Except for some build, configuration and miscellaneous files the Programming langage used in this applciation is C++. Mainly for its user friendly usage but still close to the machine. This langage is also the one I know the better and that I value the most.
Briefly describe the technology stack you opted for and why. This may include:
- Programming languages
- Databases
- CI/CD tools
- Containerization/orchestration (e.g., Docker, Kubernetes)
- Cloud providers or infrastructure (e.g., AWS, Azure, GCP)
Additional Questions for Inspiration
Our infrastructure is hosted on Amazon Wed Services cloud to be able to access our project infrastructure with any well protected web browser.
- The CI/CD runners are hosted by Gitlab.com -I use Jira for personal Project Managment because I got used to it in a previous internship -CI/CD is communicating through the GitLab CI/CD system through the commits on the local branches that directly send information to run a pipeline routine following the .gitlab-ci.yml file