diff --git a/dev/devops/Очистка Nexus Sonatype.md b/dev/devops/Очистка Nexus Sonatype.md new file mode 100644 index 00000000..18a12551 --- /dev/null +++ b/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]] +### Дополнительные материалы +- +### Дочерние заметки + diff --git a/dev/other/SNAPSHOT версионирование.md b/dev/other/SNAPSHOT версионирование.md new file mode 100644 index 00000000..36d3b24a --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + diff --git a/dev/other/Версионирование ПО.md b/dev/other/Версионирование ПО.md new file mode 100644 index 00000000..6a6fc41f --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + +- [[Семантическое версионирование]] +- [[Версионирование по дате]] +- [[Инкрементальное версионирование]] +- [[Версионирование через идентификаторы коммитов]] +- [[Версионирование по коду сборки]] +- [[SNAPSHOT версионирование]] + diff --git a/dev/other/Версионирование по дате.md b/dev/other/Версионирование по дате.md new file mode 100644 index 00000000..e5632278 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + diff --git a/dev/other/Версионирование по коду сборки.md b/dev/other/Версионирование по коду сборки.md new file mode 100644 index 00000000..9f9b7d7c --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + diff --git a/dev/other/Версионирование через идентификаторы коммитов.md b/dev/other/Версионирование через идентификаторы коммитов.md new file mode 100644 index 00000000..f69eb572 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + diff --git a/dev/other/Инкрементальное версионирование.md b/dev/other/Инкрементальное версионирование.md new file mode 100644 index 00000000..dbe5bed7 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + diff --git a/dev/other/Семантическое версионирование.md b/dev/other/Семантическое версионирование.md new file mode 100644 index 00000000..bb05533c --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки +