Версионирование ПО.md
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
Struchkov Mark 2024-10-02 21:55:54 +03:00
parent 60c252c339
commit 55507f814c
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
8 changed files with 258 additions and 0 deletions

View File

@ -0,0 +1,39 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-09-03
zero-link:
parents: []
linked:
---
Со временем артефакты будут накапливаться в Nexus и занимать дисковое пространство. Необходимо настроить политики очистки данных, а также добавить задачи на запуск по расписанию, чтобы все происходило в автоматическом режиме.
## Cleanup Policies
В настройках администрирования есть пункт `Repository > Cleanup Policies`. Он позволяет задать правила удаления артефактов.
> [!WARNING] Политики не выполняются
> На этом этапе мы лишь описываем политики. Автоматически они не применяются. Чтобы они применялись необходимо зайти в пункт `Repository > Repositories` выбрать нужный репозиторий и найти пункт Cleanup Policies, в котором можно выбрать созданные политики. Именно они и будут применяться.
>
> Но и это еще не все. Необходимо зайти в раздел `System > Tasks` и убедиться в наличии или настроить автоматическое выполнение задачи по очистке: Cleanup service. Именно она запсукает процесс очистки
## Дополнительные задачи очистки
Но и этого мало. Необходимо перейти в раздел `System > Tasks` и настроить еще несколько полезных задач.
Выполнять их лучше в определенном порядке
- **Cleanup Policies**. Выполняет ранее настроенные политики.
- **Delete Incomplete Uploads**. Предназначена для удаления неполных загрузок, которые могли возникнуть из-за прерванных или неудачных операций загрузки артефактов в репозитории.
- **Delete unused manifests and images**. Позволяет удалять docker слои, которые потеряли связь с тегами.
- **Compact Blob Store**. Предназначена для оптимизации путем удаления удаленных или помеченных на удаление блобов, которые больше не связаны с какими-либо компонентами. То есть не все удаляется, некоторые блобы помечаются к удалению, но занимают место, эта задача окончательно их удаляет.
***
## Мета информация
**Область**:: [[../../meta/zero/00 DevOps|00 DevOps]]
**Родитель**:: [[../../../../_inbox/Nexus Sonatype|Nexus Sonatype]]
**Источник**::
**Автор**::
**Создана**:: [[2024-09-03]]
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -0,0 +1,43 @@
---
aliases:
- SNAPSHOT-версии
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
parents:
linked:
---
**SNAPSHOT-версии** — это специальные версии артефактов, которые используются на этапе разработки. Они представляют собой временные или нестабильные сборки, часто изменяющиеся и обновляющиеся.
Основные особенности SNAPSHOT-версий:
- **Временный характер**: SNAPSHOT добавляется к номеру версии артефакта (например, 1.0.0-SNAPSHOT), чтобы указать, что это не финальная версия. Это означает, что код находится в активной разработке и может изменяться до выпуска стабильной версии.
- **Частые обновления**: Версии с суффиксом SNAPSHOT могут изменяться с каждой новой сборкой, даже если формально версия остаётся той же. Например, артефакт с версией 1.0.0-SNAPSHOT будет пересобираться с новыми изменениями, пока не выйдет финальная версия 1.0.0.
- **Автоматическое обновление**: В [[../../../../knowledge/dev/Система сборки|системах сборки]] SNAPSHOT-версии автоматически проверяются на наличие обновлений при каждом запуске сборочного процесса. Это упрощает интеграцию с другими компонентами и сервисами, которые тоже находятся в разработке.
- **Релизная версия**: Когда функциональность стабилизирована и протестирована, артефакт становится релизной версией, и суффикс SNAPSHOT убирается (например, 1.0.0 вместо 1.0.0-SNAPSHOT).
Несмотря на полезность SNAPSHOT-версий в управлении зависимостями и непрерывной интеграции, они имеют несколько недостатков и потенциальных проблем, которые важно учитывать:
- **Неожиданные изменения в SNAPSHOT могут сломать зависимость**. Поскольку SNAPSHOT-версии могут обновляться без изменения номера версии, приложения, которые их используют, могут внезапно перестать собираться. Например, если один разработчик обновил артефакт, другие пользователи этой зависимости могут столкнуться с неожиданными изменениями или ошибками.
- **Проблемы с кэшированием**. Системы сборки кэшируют SNAPSHOT-версии на определённый срок. Если новая версия SNAPSHOT не обновляется в репозитории, но в локальном кэше всё ещё хранится устаревшая версия, это может привести к сборке с ошибочной версией артефакта. Разработчики могут случайно использовать старую версию SNAPSHOT, не осознавая этого, что создаёт трудноуловимые ошибки.
Ошибки при работе со SNAPSHOT версиями:
- **Использование SNAPSHOT в продакшене**. ==Одна из ключевых ошибок — это применение SNAPSHOT-версий в продакшн-системах.== Это может привести к нестабильной работе приложения, так как такие версии не гарантируют стабильности и могут содержать временные или недоработанные изменения.
- **Игнорирование политики очистки репозиториев**. Из-за частых обновлений SNAPSHOT-версии могут накапливаться в репозиториях, что приводит к захламлению и затрудняет управление артефактами. Это может вызвать проблемы с дисковым пространством или усложнить поиск нужных версий.
**Как минимизировать риски при использовании SNAPSHOT-версий**:
- **Используйте SNAPSHOT только на этапах разработки**. Это основное правило. Как только функциональность готова для релиза, переходите на стабильные версии.
- **Настройте правильное управление кэшированием**. Убедитесь, что локальный кэш обновляется корректно, чтобы избежать использования устаревших версий SNAPSHOT.
- **Регулярно очищайте репозитории от старых SNAPSHOT-версий**. Настройте автоматическую очистку репозиториев, чтобы предотвратить накопление лишних артефактов и поддерживать порядок.
- [[../devops/Очистка Nexus Sonatype|Очистка Nexus Sonatype]]
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**:: [[Версионирование ПО|Версионирование ПО]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -0,0 +1,41 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-10-02
zero-link: []
parents:
linked:
---
Версионирование программного обеспечения это процесс присвоения уникальных идентификаторов версиям приложения или библиотеки, чтобы отразить состояние разработки, изменения и совместимость с предыдущими версиями. Существует несколько подходов к версионированию ПО, каждый из которых служит разным целям в зависимости от контекста проекта.
Рассмотрим основные подходы:
- [[Семантическое версионирование]]. Отлично подходит для библиотек и фреймворков, где важна совместимость и понимание изменений.
- [[Версионирование по дате]]. Удобен для продуктов с регулярными релизами, таких как операционные системы и инструменты с фиксированным расписанием обновлений.
- [[Версионирование через идентификаторы коммитов|Версионирование через идентификаторы коммитов]]. Подходят для непрерывной интеграции и проектов с частыми сборками.
- [[Версионирование по коду сборки]]. Подходят для непрерывной интеграции и проектов с частыми сборками.
- [[Инкрементальное версионирование]].
В процессе разработки могут применяться так называемые [[SNAPSHOT версионирование|SNAPSHOT-версии]], которые используются в рамках любых подходов к версионированию. SNAPSHOT-версии указывают на то, что это промежуточная, нестабильная сборка, которая может часто изменяться и обновляться до выпуска финальной версии.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**::
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Семантическое версионирование]]
- [[Версионирование по дате]]
- [[Инкрементальное версионирование]]
- [[Версионирование через идентификаторы коммитов]]
- [[Версионирование по коду сборки]]
- [[SNAPSHOT версионирование]]
<!-- SerializedQuery END -->

View File

@ -0,0 +1,28 @@
---
aliases:
- Calendar Versioning
- CalVer
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
parents:
linked:
---
Некоторые проекты используют даты выпуска как основу для номеров версий. Формат может быть разным, например, `YYYY.MM.DD` или `YYYY.MM`, где год и месяц указывают на время выпуска.
Пример: Ubuntu использует этот подход. Версии ОС обозначаются как 20.04 (апрель 2020 года) или 22.04 (апрель 2022 года).
Подходит для проектов с регулярными релизами, особенно когда стабильность важнее, чем совместимость по API.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**:: [[Версионирование ПО]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -0,0 +1,24 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
parents:
linked:
---
Часто используется в средах непрерывной интеграции (CI). В таких системах каждой новой сборке присваивается уникальный номер версии, связанный с номером сборки.
Пример: В Jenkins или TeamCity версии могут иметь формат 1.0.0+build.42, где 42 — это номер сборки.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**:: [[Версионирование ПО|Версионирование ПО]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -0,0 +1,26 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
parents:
linked:
---
Этот подход встречается в некоторых проектах с частыми сборками, особенно в open source. В этом случае номер версии может быть привязан к хешу коммита в системе контроля версий (например, Git).
Пример: Использование таких версий, как 1.0.0-ab12cd, где ab12cd — это часть SHA-хеша коммита.
Этот подход удобен для разработки и отладки, так как позволяет точно идентифицировать, какой код находится в конкретной версии.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**:: [[Версионирование ПО|Версионирование ПО]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -0,0 +1,24 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
parents:
linked:
---
Некоторые проекты используют просто инкрементирующий номер, например, версии 1, 2, 3, 4 и так далее. Этот подход не указывает на характер изменений (важные или нет) и часто используется для проектов, где структура версий не имеет ключевого значения.
Пример: Видео-игры и ПО, обновляемое ежедневно, могут использовать такой формат, так как для них важнее просто иметь новую версию, а не описывать её влияние на совместимость.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**:: [[Версионирование ПО|Версионирование ПО]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -0,0 +1,33 @@
---
aliases:
- Semantic Versioning
- SemVer
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
- "[[../../meta/zero/00 Разработка|00 Разработка]]"
parents:
- "[[Версионирование ПО|Версионирование ПО]]"
linked:
---
Этот подход наиболее широко используется в современной разработке. Он помогает ясно и однозначно определять тип изменений в программном продукте.
Формат версий: `MAJOR.MINOR.PATCH`
- **MAJOR** (основная версия) — увеличивается при внесении изменений, нарушающих обратную совместимость. Например, версия 2.0.0 может означать значительные изменения API.
- **MINOR** (дополнительная версия) — увеличивается при добавлении новой функциональности, которая сохраняет обратную совместимость. Например, версия 2.1.0 добавляет новые функции без изменений предыдущих.
- **PATCH** (исправление) — увеличивается при исправлении ошибок или внесении мелких изменений, не нарушающих API. Например, версия 2.1.1 может быть исправлением багов.
Этот подход удобен для работы с библиотеками и фреймворками, поскольку четко указывает на совместимость разных версий.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**:: [[Версионирование ПО|Версионирование ПО]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->