Версионирование ПО.md

dev/devops/Очистка Nexus Sonatype.md

@@ -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) -->

dev/other/SNAPSHOT версионирование.md

@@ -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) -->

dev/other/Версионирование ПО.md

@@ -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 -->

dev/other/Версионирование по дате.md

@@ -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) -->

dev/other/Версионирование по коду сборки.md

@@ -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) -->

dev/other/Версионирование через идентификаторы коммитов.md

@@ -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) -->

dev/other/Инкрементальное версионирование.md

@@ -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) -->

dev/other/Семантическое версионирование.md

@@ -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) -->