Project Concept description

CONCEPT.md

+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. 
+
+# 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. 
+
+1. **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 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. 
+
+2. **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. 
+
+3. **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.  
+
+4. **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. 
+
+5. **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 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
+
+1. **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. 
+
+2. **IaC**
+
+3. **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
+
+1. **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. 
+
+2. 
+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**
+<!-- 
+- **Where is your infrastructure hosted?**
+- **How do you allocate the underlying resources hosting your environments?**
+- **How is everything provisioned?** 
+- **Why did you choose one technology over another?**
+- **How does CI/CD talk to the Version Control System (VCS) and/or vice versa?**
+- **What are the names of your target environments?**
+- **How do you set up all your services? Which ones do you actually need to set up? If some services don’t need to be set up, why?**
+- **What are the differences between your environments, if any?**
+- **Would graphics or diagrams help illustrate your architecture?**
+- **What about the persistence layer (database)?** 
+
+
+
+//////////////////////////////////////////////////////////////////////////////////////////////////:::
+
+
+# Content
+
+## Life Cycle of the Application
+
+The life cycle of this application is designed to be as automated and repeatable as possible. Below are the key steps of the process:
+
+1. **Development Phase**:
+   - Developers write code using the selected technology stack.
+   - Each feature branch is created from the main branch in Git.
+   - Code is committed regularly and pushed to the remote repository.
+
+2. **Continuous Integration (CI)**:
+   - When code is pushed to the repository, the CI pipeline (set up in GitHub Actions or GitLab CI) triggers automatically.
+   - The pipeline runs tests, lints the code, and builds the project to ensure that no errors or regressions are introduced.
+
+3. **Continuous Deployment (CD)**:
+   - Upon successful integration, the CD pipeline automatically deploys the application to a staging environment.
+   - Once verified, the application is deployed to production.
+   - Any issues that arise in production are flagged in the monitoring systems and resolved through additional commits.
+
+4. **Monitoring and Feedback**:
+   - Real-time logging and monitoring services (e.g., Prometheus, Grafana) collect performance and error data.
+   - This feedback loop ensures continuous improvements and bug fixing.
+
+## Infrastructure Architecture and Provisioning
+
+The infrastructure for this application is provisioned and managed using the following tools and services:
+
+1. **Cloud Provider**:
+   - The infrastructure is hosted on **AWS (Amazon Web Services)**, leveraging its elasticity and scalability features.
+   
+2. **Infrastructure as Code (IaC)**:
+   - We use **Terraform** for provisioning and managing cloud resources. Terraform scripts define and automate the setup of virtual machines (EC2 instances), databases (RDS), and networking (VPC).
+   
+3. **Containerization**:
+   - The application is packaged into **Docker containers** to ensure consistency across development, staging, and production environments.
+   - **Kubernetes** is used for orchestration and management of containerized applications, allowing for easy scaling, load balancing, and fault tolerance.
+
+4. **Continuous Deployment Pipeline**:
+   - A CI/CD pipeline using **GitHub Actions** ensures that code is automatically built, tested, and deployed.
+   - Deployment to staging and production is handled by Terraform using the `terraform apply` command to provision infrastructure and deploy the application.
+
+## Explanation of Decisions
+
+- **AWS vs. Azure/GCP**: We chose **AWS** as our cloud provider because of its well-established services, broad documentation, and flexibility in offering services that suit our project needs (e.g., EC2, RDS, EKS).
+  
+- **Docker & Kubernetes**: Containerization with **Docker** ensures that the application runs consistently across all environments. **Kubernetes** was selected for container orchestration due to its scalability and ability to manage the complexity of deploying applications at scale.
+  
+- **Terraform for IaC**: Terraform was chosen for infrastructure management due to its support for multi-cloud environments, flexibility in resource provisioning, and the fact that it integrates seamlessly with both AWS and Kubernetes.
+
+- **GitHub Actions for CI/CD**: GitHub Actions offers native integration with GitHub repositories, making it the most suitable option for automated builds, tests, and deployments. It also supports flexible workflows and can trigger actions based on events in the repository (like a push or pull request).
+
+## Technology Stack
+
+The technology stack for this application was selected based on scalability, cost-efficiency, and familiarity with the development team. Here’s a breakdown:
+
+1. **Programming Language**: **Node.js** (JavaScript) is used for the application’s back end, as it offers asynchronous, event-driven architecture that is well-suited for scalable, high-performance applications.
+   
+2. **Database**: We are using **Amazon RDS (PostgreSQL)** for data persistence. PostgreSQL was chosen for its reliability, support for ACID transactions, and compatibility with relational data models.
+
+3. **Containerization**: 
+   - **Docker** is used to containerize the application, ensuring consistency between development, staging, and production environments.
+   - **Kubernetes (EKS)** is used for orchestrating Docker containers at scale on AWS.
+   
+4. **CI/CD**: 
+   - **GitHub Actions** for Continuous Integration and Continuous Deployment ensures that the code is automatically tested, built, and deployed.
+   
+5. **Monitoring**: 
+   - **Prometheus** and **Grafana** are used for real-time monitoring, providing detailed insights into system performance and uptime.
+
+## Additional Considerations
+
+### Where is your infrastructure hosted?
+- The infrastructure is hosted on **AWS** to leverage the scalability and managed services offered by Amazon, including EC2 instances, RDS for database management, and EKS for container orchestration.
+
+### How do you allocate the underlying resources hosting your environments?
+- Resources are allocated dynamically using **Terraform**, which provisions and manages resources like EC2 instances, RDS instances, and VPC networks. We can scale resources up or down as needed based on the traffic and load.
+
+### How is everything provisioned?
+- **Terraform** scripts are used to automate the provisioning of the infrastructure and deployment of the application. This includes configuring the networking layer, databases, and Kubernetes clusters, ensuring a repeatable and predictable deployment process.
+
+### Why did you choose one technology over the other?
+- **Node.js** was chosen for its asynchronous, non-blocking I/O model, making it suitable for real-time applications.
+- **AWS** was selected because of its robust set of cloud services, wide adoption, and support for scaling applications.
+- **Terraform** is chosen for its flexibility and ability to work with multiple cloud providers, allowing for easy replication and management of infrastructure.
+
+### What are the names of your target environments?
+- **Development**: For local development environments and initial testing.
+- **Staging**: A replica of the production environment used for testing new features.
+- **Production**: The live environment where users interact with the application.
+
+### How do you set up all your services?
+- Services are set up through automated pipelines in **GitHub Actions**. The CI pipeline ensures the code is built and tested, while the CD pipeline automatically deploys it to staging and production environments using Terraform and Kubernetes.
+
+### What are the differences between your environments, if any?
+- **Development** is usually a local environment where developers run services in containers using Docker. **Staging** mimics the production environment, with an identical configuration to test changes before pushing them live. **Production** has additional monitoring and scaling configurations to handle real-world traffic.
+
+### Would some graphic(s) better illustrate your architectural design?
+- Yes, including diagrams of the architecture, CI/CD pipelines, and Kubernetes cluster setup would help visualize how the components interact.
+
+### What about the persistence layer (database)?
+- The **PostgreSQL** database is hosted on **Amazon RDS** for high availability, automatic backups, and scalability. It supports the application’s relational data model and is fully managed, reducing overhead for maintenance and administration.
+ -->

lib/x86_64-w64-mingw32/root/bin/pkg-config

+#!/bin/sh -e
+
+# This is a wrapper for pkg-config which helps with cross-compiling;
+# it sets up environment variables to pkg-config searches for
+# libraries in the sysroot where a copy of this script is located.
+
+BIN=`dirname $0`
+ROOT=`dirname "$BIN"`
+
+export PKG_CONFIG_DIR=
+export PKG_CONFIG_LIBDIR="${ROOT}/lib/pkgconfig:${ROOT}/share/pkgconfig"
+
+exec pkg-config "$@"