Онбординг — инструменты и окружение

Стартовая страница для нового разработчика или аутсорс-подрядчика: рабочее окружение, доступы и путь задачи от постановки до прода.

Что поставить

Инструмент	Зачем	Примечание
Платформа 1С с Конфигуратором	Среда разработки	Версия — та же, что на проде базы, с которой работаете. Среда зафиксирована: Конфигуратор, не EDT
git	Все исходники и поставки — через git (стандарт)	Git for Windows достаточно
VS Code + расширение Language 1C (BSL)	Локальный линт BSL Language Server по исходникам	Диагностики линтера связаны со стандартами — чип на странице стандарта ведёт к описанию
OneScript + opm	Скрипты автоматизации (vrunner, gitsync)	Пока опционально — понадобится с запуском CI-контура (см. шаблоны CI)

Какие доступы запросить

• Тестовые базы своего проекта — вся разработка и проверка живёт здесь; что можно в каком контуре — в стандарте «Контуры баз». Доступа в прод у разработчика нет — это норма, а не недоработка.
• Git-сервер — репозитории расширений/конфигураций.
• База знаний — паспорта интеграций, реестры регламентных заданий, ADR.
• Трекер задач — задача есть у любой работы; поставки «по переписке» не принимаются.

Как устроены правила

• У каждого стандарта есть уровень (бейдж под заголовком): директива — обязательна и автоматически становится пунктом чеклиста; рекомендация — сильный дефолт. У директив есть раздел «Когда не применять» — законные исключения.
• Чеклист подбирается по типу задачи (карточки на главной) и проходится по ходу работы, плюс «Базовая проверка» — общая для всех.
• Начать чтение стоит с пяти стандартов из блока «С чего начать новичку» на главной.

Путь задачи

1. Возьмите задачу в трекере и определите её тип (интеграция, отчёт, ВПФ, форма…). Сразу откройте чеклист этого типа + базовый, укажите № задачи.

2. Заведите ветку (GitFlow: feature/<номер-задачи>); при работе через хранилище — захват объектов и помещения с номером задачи в комментарии.

3. Разрабатывайте по стандартам. Собственные объекты в типовых конфигурациях — только с префиксом КИ_ / ДД_ (код-стайл).

4. Прогоните линт локально (BSL LS в VS Code) и пройдите чеклист до конца; результат выгрузите в Markdown/PDF и приложите к задаче.

5. Откройте MR по шаблону описания изменения — что, зачем, как проверить, ссылка на чеклист. Бинарные .cfe/.epf вместо исходников не принимаются.

6. Ревью и приёмка: замечания правятся в той же ветке; проверка — на тестовой базе с боевыми данными, в прод изменение едет только после неё.

Куда смотреть при вопросах

• Поиск по этому сайту — стандарты отвечают «как правильно, как неправильно и когда правило не действует».
• Источники и инструменты — первоисточники v8std, чужие гайды, инструменты качества.
• Не нашли ответа — вопрос техлиду внутренней команды; повторяющиеся вопросы становятся новыми стандартами.