| |
@@ -528,32 +528,64 @@
|
| |
Please check the answer to the user story #51.
|
| |
|
| |
81. **Scalability - As a SaaS administrator, I want the system architecture to support scalability, manually or automatically based on demand, so that we can maintain optimal performance during traffic spikes and efficiently handle user growth.**
|
| |
- Gitlab provides reference architectures which you can use when determining what level of users and interactions we require a deployment to be able to service comfortably. This is best done prior to installation as it is potentially not easy to change after the fact. If we choose to deploy gitlab within a cloud provider such as AWS we can take advantage of auto scaling features. See the reference architectures here:
|
| |
+ Gitlab provides reference architectures which you can use when determining what level of
|
| |
+ users and interactions we require a deployment to be able to service comfortably. This is
|
| |
+ best done prior to installation as it is potentially not easy to change after the fact. If
|
| |
+ we choose to deploy gitlab within a cloud provider such as AWS we can take advantage of auto
|
| |
+ scaling features. See the reference architectures here:
|
| |
https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html
|
| |
|
| |
82. **Reliability and High Availability - User Story: As a SaaS administrator, I want the service architecture to be highly available, to ensure 24/7 operation with minimal downtime, so that end users may access and use the application whenever needed without interruptions.**
|
| |
- Gitlab architecture offers the ability to run in a highly available fashion. Ensure a suitable configuration is deployed at installation time. It is not easily changed later. See the reference architecture here: https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html there are a number of maintenance tasks which must be carried out regularly to maintain the instance see: https://docs.gitlab.com/ee/administration/operations/
|
| |
+ Gitlab architecture offers the ability to run in a highly available fashion. Ensure a
|
| |
+ suitable configuration is deployed at installation time. It is not easily changed later. See
|
| |
+ the reference architecture here:
|
| |
+ https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html there are a
|
| |
+ number of maintenance tasks which must be carried out regularly to maintain the instance
|
| |
+ see: https://docs.gitlab.com/ee/administration/operations/
|
| |
|
| |
83. **Security - User Story: As a SaaS administrator, I want robust security measures implemented across our infrastructure, including encryption, access controls, and regular security audits, so that we can protect our end users data and maintain their trust.**
|
| |
- Gitlab has robust security features, if installed, configured and maintained correctly, the system can be secure enough for our needs in a self managed installation. We need to ensure that we follow the best practices during the installation phase. https://docs.gitlab.com/ee/security/ for notes related to security breech see https://docs.gitlab.com/ee/security/responding_to_security_incidents.html and for recomendations to hardening the installation https://docs.gitlab.com/ee/security/hardening.html
|
| |
+ Gitlab has robust security features, if installed, configured and maintained correctly, the
|
| |
+ system can be secure enough for our needs in a self managed installation. We need to ensure
|
| |
+ that we follow the best practices during the installation phase.
|
| |
+ https://docs.gitlab.com/ee/security/ for notes related to security breach see
|
| |
+ https://docs.gitlab.com/ee/security/responding_to_security_incidents.html and for
|
| |
+ recommendations to hardening the installation
|
| |
+ https://docs.gitlab.com/ee/security/hardening.html
|
| |
|
| |
84. **Security - User Story: As a SaaS administrator, I want to quickly identify when the system is affected by CVEs, so that steps can be taken to plan upgrades to mitigate vulnerabilities.**
|
| |
- Gitlab notifies when the system is affected by known CVEs, popups suggesting the system be updated show to administrators on logging into the system. See information about patching and maintenance with regards to upgrading and mitigating vulnerabilities https://docs.gitlab.com/ee/policy/maintenance.html
|
| |
+ Gitlab notifies when the system is affected by known CVEs, popups suggesting the system be
|
| |
+ updated show to administrators on logging into the system. See information about patching
|
| |
+ and maintenance with regards to upgrading and mitigating vulnerabilities
|
| |
+ https://docs.gitlab.com/ee/policy/maintenance.html
|
| |
|
| |
85. **Monitoring and Observability - User Story: As a SaaS administrator, I want a centralised monitoring and logging system that provides real-time insights into application performance, resource utilisation, and user experience, so that we can quickly identify and resolve issues before they impact users.**
|
| |
- Gitlab has integrations with prometheus and grafana to provide monitoring. See https://docs.gitlab.com/ee/administration/monitoring/ This can be scraped by Zabbix later as we move towards using Zabbix as the main monitoring system within Fedora Infra.
|
| |
+ Gitlab has integrations with prometheus and grafana to provide monitoring. See
|
| |
+ https://docs.gitlab.com/ee/administration/monitoring/ This can be scraped by Zabbix later as
|
| |
+ we move towards using Zabbix as the main monitoring system within Fedora Infra.
|
| |
|
| |
86. **Infrastructure as Code (IaC) - User Story: As a SaaS administrator, I want to manage our the system infrastructure using code that we can version control, easily replicate environments, and automate provisioning and configuration.**
|
| |
- Configuration will be possible to keep under source control. Depending on the method of installation we choose, there are Linux packages, Helm, Docker, Operator, source, or scripts. It will likely require that we develop configurations to add custom functionality such as integrations with FAS. https://docs.gitlab.com/ee/install/
|
| |
+ Configuration will be possible to keep under source control. Depending on the method of
|
| |
+ installation we choose, there are Linux packages, Helm, Docker, Operator, source, or
|
| |
+ scripts. It will likely require that we develop configurations to add custom functionality
|
| |
+ such as integrations with FAS. https://docs.gitlab.com/ee/install/
|
| |
|
| |
87. **Multi-tenancy - User Story: As a SaaS administrator, I want the application to be a secure multi-tenant system that efficiently shares resources among end users while ensuring complete data isolation, so that we can serve multiple clients cost-effectively without compromising security.**
|
| |
- By default, Gitlab is configured for multi-tenancy. The reference architectures detail the requirements to guarantee a service level capable of supporting the desired number of users.
|
| |
+ By default, Gitlab is configured for multi-tenancy. The reference architectures detail the
|
| |
+ requirements to guarantee a service level capable of supporting the desired number of users.
|
| |
|
| |
88. **Disaster Recovery and Backup - User Story: As a SaaS administrator, I want automated backup systems and a comprehensive disaster recovery plan in place, so that we can quickly recover from any unforeseen events and minimise data loss and downtime.**
|
| |
- The process for backing up and restoration of Gitlab instances is well documented see: https://docs.gitlab.com/ee/administration/backup_restore/index.html and restoring see https://docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html
|
| |
+ The process for backing up and restoration of Gitlab instances is well documented see:
|
| |
+ https://docs.gitlab.com/ee/administration/backup_restore/index.html and restoring see
|
| |
+ https://docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html
|
| |
|
| |
89. **Upgradability - User Story: As a SaaS administrator, I want to apply automated system upgrades, preferrably without causing system downtime, so we can continue to provide service to end users.**
|
| |
- Gitlab can be upgraded, but not automated, and probably not without downtime or degraded performace. See the guide depending on the installation method we go with: https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method
|
| |
+ Gitlab can be upgraded, but not automated, and probably not without downtime or degraded
|
| |
+ performace. See the guide depending on the installation method we go with:
|
| |
+ https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method
|
| |
|
| |
90. **Upgradability - User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.**
|
| |
- The Gitlab system can be upgraded safely, but not automatically, see the upgrade guide for more information depending on the method of installation we choose https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method and migrations also likely required to be carried out see https://docs.gitlab.com/ee/update/background_migrations.html
|
| |
+ The Gitlab system can be upgraded safely, but not automatically, see the upgrade guide for
|
| |
+ more information depending on the method of installation we choose
|
| |
+ https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method
|
| |
+ and migrations also likely required to be carried out see
|
| |
+ https://docs.gitlab.com/ee/update/background_migrations.html
|
| |
t0xic0der
commented 7 months ago
Signed-off-by: Akashdeep Dhar akashdeep.dhar@gmail.com
cc @ryanlerch