|
| 1 | +# Как вносить изменения и вариант тестирования |
| 2 | + |
| 3 | +## Процесс разработки |
| 4 | + |
| 5 | +### 1. Создание новой ветки |
| 6 | + |
| 7 | +Создайте новую ветку для ваших изменений: |
| 8 | + |
| 9 | +```bash |
| 10 | +git checkout -b flant/TASKID-your-feature-name |
| 11 | +``` |
| 12 | + |
| 13 | +### 2. Внесение изменений в код |
| 14 | + |
| 15 | +При добавлении нового функционала следуйте следующим правилам: |
| 16 | + |
| 17 | +#### 2.1. Добавление новых флагов |
| 18 | + |
| 19 | +Если вы добавляете новый флаг или переменную окружения: |
| 20 | + |
| 21 | +1. **Описание флага** в `ENVIRONMENT_VARIABLES_AND_FLAGS.md`: |
| 22 | + - Добавьте флаг в соответствующую секцию команды |
| 23 | + - Укажите переменную окружения |
| 24 | + - Добавьте описание и значение по умолчанию |
| 25 | + |
| 26 | +2. **Конфигурация** в `config.yaml`: |
| 27 | + - Добавьте соответствующий ключ в секцию команды или в общие настройки |
| 28 | + - Укажите значение по умолчанию |
| 29 | + |
| 30 | +3. **Обработка флага** в `pkg/config/config.go`: |
| 31 | + - Добавьте поле в структуру `Config` и/или `CommandConfig` |
| 32 | + - Добавьте загрузку значения через `getValue()` в функции `LoadConfig` |
| 33 | + - При необходимости добавьте флаг в `CommandFlags` для автоматического добавления к команде |
| 34 | + - При необходимости добавьте валидацию |
| 35 | + |
| 36 | +4. **Использование флага** в команде: |
| 37 | + - Получайте значение через `config.GetCommandConfig(cmd)` или `config.GetConfig()` |
| 38 | + - Используйте соответствующие методы get* если они доступны |
| 39 | + |
| 40 | +#### 2.2. Описание логики в ARCHITECTURE.md |
| 41 | + |
| 42 | +**Обязательно** опишите всю новую логику в `ARCHITECTURE.md`: |
| 43 | + |
| 44 | +- Добавьте или обновите алгоритм команды в разделе "Алгоритмы для каждого флага" |
| 45 | +- Опишите каждый шаг выполнения |
| 46 | +- Укажите используемые API endpoints |
| 47 | +- Опишите обработку всех возможных вариантов поведения |
| 48 | +- Укажите особенности dry-run режима если команда его поддерживает |
| 49 | +- Обновите секцию "Конфигурация" для команды |
| 50 | + |
| 51 | +#### 2.3. Общие принципы |
| 52 | + |
| 53 | +- Вся обработка флагов и конфигурации должна быть централизована в `pkg/config/` |
| 54 | +- Используйте существующие утилиты из `pkg/utils/` где возможно |
| 55 | +- Избегайте дублирования кода - выносите общую логику в утилиты |
| 56 | +- Все команды должны поддерживать `--dry-run` где это применимо |
| 57 | +- Логирование должно быть информативным и структурированным |
| 58 | + |
| 59 | +### 3. Билд и перенос в кластер |
| 60 | + |
| 61 | +#### 3.1. Сборка бинарника |
| 62 | + |
| 63 | +Соберите бинарник: |
| 64 | + |
| 65 | +```bash |
| 66 | +go build -o osctl cmd/main.go |
| 67 | +``` |
| 68 | + |
| 69 | +#### 3.2. Перенос в кластер |
| 70 | + |
| 71 | +Скопируйте бинарник на мастер-ноду кластера: |
| 72 | + |
| 73 | +```bash |
| 74 | +scp osctl ИМЯ_НОДЫ-a-ks-master-0:/tmp |
| 75 | +``` |
| 76 | + |
| 77 | +### 4. Тестирование в кластере |
| 78 | + |
| 79 | +#### 4.1. Подготовка деплоймента |
| 80 | + |
| 81 | +1. В нужном namespace создайте деплоймент из `config-example/test-deployment.yaml`: |
| 82 | + |
| 83 | +```bash |
| 84 | +kubectl -n infra-elklogs apply -f config-example/test-deployment.yaml |
| 85 | +``` |
| 86 | + |
| 87 | +#### 4.2. Копирование файлов в под |
| 88 | + |
| 89 | +1. Скопируйте новый бинарник в под: |
| 90 | + |
| 91 | +```bash |
| 92 | +kubectl -n infra-elklogs cp /tmp/osctl <pod-name>:/tmp |
| 93 | +``` |
| 94 | + |
| 95 | +2. Скопируйте конфигурационные файлы в под: |
| 96 | + |
| 97 | +```bash |
| 98 | +kubectl -n infra-elklogs cp config.yaml <pod-name>:/tmp |
| 99 | +kubectl -n infra-elklogs cp osctlindicesconfig.yaml <pod-name>:/tmp |
| 100 | +kubectl -n infra-elklogs cp osctltenants.yaml <pod-name>:/tmp |
| 101 | +``` |
| 102 | + |
| 103 | +#### 4.3. Тестирование |
| 104 | + |
| 105 | +1. Проводим прямо из оболочки пода: |
| 106 | + |
| 107 | +```bash |
| 108 | +kubectl -n infra-elklogs exec -ti <pod-name> -- bash |
| 109 | +``` |
| 110 | + |
| 111 | +2. Перейдите в `/tmp`: |
| 112 | + |
| 113 | +```bash |
| 114 | +cd /tmp |
| 115 | +``` |
| 116 | + |
| 117 | +3. Проверьте команды с `--dry-run`: |
| 118 | + |
| 119 | +```bash |
| 120 | +./osctl <command> --dry-run |
| 121 | +``` |
| 122 | + |
| 123 | +Например: |
| 124 | + |
| 125 | +```bash |
| 126 | +./osctl snapshots --dry-run |
| 127 | +./osctl sharding --dry-run |
| 128 | +./osctl retention --dry-run |
| 129 | +``` |
| 130 | + |
| 131 | +4. Проверьте работу без `--dry-run` (если уверены в безопасности): |
| 132 | + |
| 133 | +```bash |
| 134 | +./osctl <command> |
| 135 | +``` |
| 136 | + |
| 137 | +#### 4.4. Полезные команды |
| 138 | + |
| 139 | +- Проверка списка доступных команд: `./osctl --help` |
| 140 | +- Проверка справки по команде: `./osctl <command> --help` |
| 141 | +- Просмотр логов с детализацией: используйте логирование через logger |
| 142 | + |
| 143 | +### 5. Коммит и push |
| 144 | + |
| 145 | +После тестирования: |
| 146 | + |
| 147 | +```bash |
| 148 | +git add . |
| 149 | +git commit -m "feat: описание изменений" |
| 150 | +git push origin feature/your-feature-name |
| 151 | +``` |
| 152 | + |
| 153 | +### 6. Создание Pull Request |
| 154 | + |
| 155 | +Создайте Pull Request с описанием изменений и проверьте: |
| 156 | + |
| 157 | +- ✅ Все новые флаги описаны в `ENVIRONMENT_VARIABLES_AND_FLAGS.md` |
| 158 | +- ✅ Все новые ключи добавлены в `config.yaml` |
| 159 | +- ✅ Вся логика описана в `ARCHITECTURE.md` |
| 160 | +- ✅ Код прошел линтер без ошибок |
| 161 | +- ✅ Изменения протестированы в кластере |
| 162 | + |
| 163 | +## Полезные ссылки |
| 164 | + |
| 165 | +- [ENVIRONMENT_VARIABLES_AND_FLAGS.md](ENVIRONMENT_VARIABLES_AND_FLAGS.md) - Полный справочник по флагам и переменным окружения |
| 166 | +- [ARCHITECTURE.md](ARCHITECTURE.md) - Подробные алгоритмы и архитектура системы |
| 167 | +- [README.md](README.md) - Основная документация проекта |
| 168 | + |
0 commit comments