This commit is contained in:
parent
60c252c339
commit
55507f814c
39
dev/devops/Очистка Nexus Sonatype.md
Normal file
39
dev/devops/Очистка Nexus Sonatype.md
Normal 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) -->
|
43
dev/other/SNAPSHOT версионирование.md
Normal file
43
dev/other/SNAPSHOT версионирование.md
Normal 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) -->
|
41
dev/other/Версионирование ПО.md
Normal file
41
dev/other/Версионирование ПО.md
Normal 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 -->
|
28
dev/other/Версионирование по дате.md
Normal file
28
dev/other/Версионирование по дате.md
Normal 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) -->
|
24
dev/other/Версионирование по коду сборки.md
Normal file
24
dev/other/Версионирование по коду сборки.md
Normal 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) -->
|
26
dev/other/Версионирование через идентификаторы коммитов.md
Normal file
26
dev/other/Версионирование через идентификаторы коммитов.md
Normal 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) -->
|
24
dev/other/Инкрементальное версионирование.md
Normal file
24
dev/other/Инкрементальное версионирование.md
Normal 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) -->
|
33
dev/other/Семантическое версионирование.md
Normal file
33
dev/other/Семантическое версионирование.md
Normal 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) -->
|
Loading…
Reference in New Issue
Block a user