Технологии

На этом этапе мы работаем с IT-службой Заказчика: разрабатываем API обмена, проектируем каналы обмена данными. Результат: одно- или двусторонний обмен с 1С, ERP, AXAPTA, SAP и еще 20+ менее известными системами учета и автоматизации.

Мы настроим Вам CRM (Битрикс24, AMOCrm или RetailCRM), после чего у Вас будут детальные отчеты по продажам, «нарезка» по разным типам Клиентов — для SMS и e-mail рассылок, а также аналитика по прибыли в разрезе источников рекламы и типов товаров/услуг.

У нас свои инженеры DevOps: построим оптимальную схему развертывания обновлений, настроим кластер, проведем нагрузочное тестирование. А после запуска проекта - обеспечим надзор 24/7.

1. Установка продукта. Настройка основной площадки перед началом работ

Перед стартом начала работ важно правильно настроить основную площадку (main), чтобы при создании площадок для разработки уже всё было настроено.

1.1. Установка и проверка bitrix перед стартом работ

Сайт устанавливается СТРОГО в кодировке UTF-8.
ПРОВЕРКА: при проверке сайта (Инструменты — проверка системы) шестым пунктов проверки должно выводиться «Параметры настройки UTF».
Сайт ни в коем случае не ставится на демо-ключе. Ключ в обязательном порядке запрашивается у менеджера проекта, в случае непредставления проект останавливается.
ПРОВЕРКА: Marketplace — обновление платформы — посмотреть ключ.
Сразу после установки необходимо зайти в обновления и установить все обновления системы.
ПРОВЕРКА: зайти и поставить самому.
После разворачивания сайта необходимо пройти проверку системы и проверку тестирования конфигурации /bitrix/admin/site_checker.php?lang=ru. Ошибок и предупреждений не должно быть. По умолчанию агенты на тестовых площадках Extyl должны выполняться на хитах, а на бою переведены на cron (тимлид проекта решает когда на тесте надо перевести агента на cron).
Запрет отправки почтовых сообщений на тестовой площадке. Если на странице задана константа ONLY_EMAIL и email из настроек почтового шаблона с ее значением не совпадает, то письмо не отсылать. Если мы хотим запретить отсылать сообщения на всем сайте, то необходимо в файле bdconn.php установить константу define("ONLY_EMAIL", "admin@site.ru").

1.2. Настройка robots.txt после разворачивания сайта. SEO. Первейшие вещи

Сразу после установки необходимо в robots.txt прописать правило:

User-Agent: *
Disallow: /

#Все другие правила удалить
– запрещена индексация сайта; во время запуска сайта файл должен быть изменен (должны быть запрещены к индексации только системные папки, такие как bitrix, upload, auth и т.п.).

1.3. Установка модуля миграций сущностей БД

Для переноса изменения из БД теста на бой или наоборот, надо сразу установить модуль миграции для разработчиков.
https://marketplace.1c-bitrix.ru/solutions/sprint.migration/.
Перенос изменений руками или отдельным файлом является грубой ошибкой.
При создании любого инфоблока, формы и т.д, даже если нет боя, необходимо создавать миграцию.

1.4. Установка и настройка GIT на проекте

В современных реалиях без GIT не может существовать не один проект, даже очень маленький. Все аргументы разработчиков не использовать GIT говорят лишь о незнаниях данной системы и о низкой квалификации данного разработчика. GIT — это не только правило хорошего тона, но и суровая необходимость современного подхода к разработке.
Сразу после установки надо установить GIT на проект и настроить правильно .gitignore. Пример настройки .gitignore:

/bitrix/
/bitrix
/upload/
/upload
/local/vendor/
/local/vendor
/web.config
/.htaccess
/robots.txt
/*.xml
*.swp
*.log
*.zip
*.tar
*.rar
*.gz

• Если в .gitignore положили всю папку /bitrix, но нам нужно работать с каким-то шаблоном, то его можно вернуть в git при помощи:

!/bitrix/templates/learning_10_0_0/ .

• .gitignore может быть изменен и дополнен в зависимости от потребностей проекта.
• robots.txt, как и sitemap*.xml, .htaccess должен быть в .gitignore на бою и всех тестовых площадках.
• На предпроде должна быть включена ветка stage, а на бою master. В ветках stage и master мы не работаем.
• Все ненужные страницы и разделы необходимо удалить перед первым коммитом.
• В GIT не должны попадать отладочные скрипты, логи, медиафайлы регистрируемые в БД и др.
• Очень важно первично правильно настроить GIT и сделать площадку main (stage) чистой без не закоммиченных файлов. Далее эта площадка будет копироваться на тестовые хосты и если не выполнить эти предписания, то будет куча проблем.

1.5. Установка и настройка PHP Linter на проекте

На каждом проекте в обязательном порядке устанавливается — Linter: Code Sniffer.

2. Правила разработки продукта

2.1. Требования к юзабилити разрабатываемых продуктов

При разработке нового или доработке существующего функционала не должна теряться функциональность и удобство использования штатного функционала.
При разработке нового или доработке существующего функционала обязательно думаем о удобстве администрирования (редактирования, добавления) контента на сайте. С готовым продуктом будет работать обычный человек, а не программист. Источники данных должны быть максимально информативно называться в административной части портала. Везде в публичке сайта должны работать визуальные редакторы для наполнения и редактирования контента, включаемых областей и др. Все должно быть предельно просто для заказчика.

2.2. Правила написания PHP-кода на проекте.

В общем случае обязательно использование API Bitrix (вместо PHP-кода). Если у bitrix есть функционал заменяющий чистый PHP, то надо использовать именно первое.
Пример: $_GET, $_POST, $_REQUEST - использовать запрещено!
Прямые запросы к БД - использовать запрещено!
При разработке использовать ядро D7, т.к. старое ядро устарело и битрикс настаивает на использовании именно его. Названия переменных должны быть осмысленные, переменных типа «a», «tempconst» и т.п. быть не должно. ПРОВЕРКА: достаточно посмотреть /local/php_interface/ - и файлы php внутри.
В компонентах недопустимо использовать ID-инфоблоков и ID-свойств. Необходимо динамически через хелпер получать по коду инфоблока или по коду свойства ID инфоблока или свойства (про свойство если такое надо) Необходимо придерживаться строгому регламенту стиля написания кода - Регламент по стилю написания кода (ТО) Придерживание MVC-подхода, если такой не противоречит общим правилам разработки Bitrix.

2.3. Инфоблоки их создание и настройка

В настройках инфоблока необходимо выбирать хранение свойств в отдельной таблице.
Все инфоблоки – каталог, новости и т.п., должны быть изначально настроены с ЧПУ (автоматическая транслитерация русских слов), используя штатные средства Битрикс.
ПРОВЕРКА: Контент – инфоблоки – типы инфоблоков. Смотрим поле «URL страницы детального просмотра» и URL раздела – адреса должны быть ЧПУ-вида (без знаков вида «?ID=#ID#» - вот этот знак вопроса показывает, что это параметр, такого быть не должно).
При создании нового инфоблока необходимо также настроить административную панель, а именно: отображение только тех свойств, которые реально применяются на сайте (например, если анонсовое описание не используется – скрываем его), сами же свойства нужно сгруппировать, если это применимо. А сами актуальные свойства необходимо назвать так, чтобы было понятно, зачем они нужны, пример: «описание товара в карточке товара» вместо «детальное описание».
Созданные инфоблоки должны быть разбиты по типам с корректным названием. Например инфоблок «Баннеры» не должен иметь тип «Новости».
В каждом инфоблоке нужно вдумчиво пометить те свойства, которые должны участвовать в поиске. Например, для каталога товаров это артикул и большая часть свойств и т.д.

2.4. Шаблоны сайта и интеграция верстки

Вся разработка на сайте с ноля ведется в папке /local. Папка /bitrix должна быть в .gitignore .
Все ненужные страницы и разделы необходимо удалить перед началом работы включая лишние шаблоны в папке /bitrix/templates/.
ПРОВЕРКА: сначала в разделе «Настройки» - «Сайты» посмотреть, какие шаблоны используются. Затем в указанной выше папке посмотреть и описать, что лишнее (НЕ УДАЛЯТЬ).
Примечание: .default – шаблон по умолчанию, удалять не надо.
При интеграции вёрстки (имеется ввиду разработка сайта с нуля) файлы стилей, скриптов, картинок необходимо разместить в папке шаблона (css, js, images).
ПРОВЕРКА: папка шаблона – это /local/templates/ИМЯ_ШАБЛОНА/
Не допускается вносить изменения в файлы css предоставленные верстальщиком. Если нужно поправить вёрстку необходимо прописать новые стили в другом файле (например style.css).
ПРОВЕРКА: сравнить файлы по размеру и количеству строк. Как правило, этого достаточно.
Блоки типа телефона, рекламного текста и т.д. необходимо сделать включаемой областью, причем она должна редактироваться как html только если там нет дивов, спанов и т.д. В противном случае она должна редактироваться как PHP. ПРОВЕРКА: зайти под админом на сайт, включить режим редактирования – посмотреть, как и что редактируется. Проверить, что все редактируется и ничего не ломается.
У всех изображений должен быть прописан атрибут alt. Всегда! Это нужно для SEO.
Например, для превью новости alt должен быть заголовок новости.

2.5. Модули (свои и стандартные – все)

В модулях надо использовать сервисный подход.
Кто не знает что это такое, то срочно надо освежить знания.

2.6. Компоненты (свои и стандартные – все)

В компонентах недопустимо использовать ID-инфоблоков и ID-свойств. Необходимо динамически через хелпер получать по коду инфоблока или по коду свойства ID инфоблока или свойства (про свойство если такое надо).
При интеграции шаблона компонента на сайт необходимо поддерживать интерфейс «Эрмитаж» (чтобы в режиме редактирования сайта можно было удалять, редактировать и добавлять элементы ИБ прямо на сайте, вне админки).
ПРОВЕРКА: в режиме редактирования идем на страницу с инфоблоками – списки элементов, деталки элемента. При наведении мышки кроме штатной «шестеренки» настроек компонента должны появляться кнопки «добавить» «редактировать», «удалить» элемент.
Пространство имен должно называться extyl-pro' Нестандартные модули и компоненты должны быть кратко документированы.
Пример: Компонент extyl-pro:news.list (/local/components/), отличается от стандартного тем, что собирает данные из двух инфоблоков и внешней RSS-ленты. ПРОВЕРКА: идем в папку /bitrix/components/ - внутри, кроме папок «bitrix» не должно быть иных папок. Исключение – сторонние модули Marketplace. Смотрим их наличие в ТЗ или уточняем у менеджера проекта.
Все собственные компоненты создаём в папке /local/components/extyl-pro/* Необходимо избегать кастомизацию компонентов в тех ситуациях, когда есть возможность обойтись без неё. В папке local/components/bitrix/ - не должно быть пространства имён bitrix
ПРОВЕРКА: пробежаться по нестандартным компонентам – по названию должно быть понятно, где используются, и сравнить с ТЗ – где действительно они нужны.

2.7. Формы обратной связи и т.п.

Формы обратной связи и т.п. запросов – все – должны работать через модуль «Вебформы». В шаблонах web-форм не должно быть привязки к id-полей форм. ID-ники должны проставляться динамически. При переносе настроек web-форм мигратором id-на площадке разработки и бою будут различаться.
Во всех формах нажатие кнопки «Enter» должно приводить к отправке формы, если в конце формы есть одна кнопка отправки (т.е. нет выбора отправить так или эдак).
ПРОВЕРКА: зайти в «Сервисы» и далее соответственно в веб-формы или в баннеры. Увидеть там все формы и все баннеры сайта.

2.8. Баннеры

Все баннеры и т.п. сменяющиеся элементы (например, фон экрана) – должны работать через модуль «Баннеры». Исключения оговариваются до реализации, а не после.

2.9. Капча

Если используем кастомную капчу (Google и др.), то необходимо предусмотреть момент, что капча может отвалиться из-за всевозможных блокировок или сбоев у провайдеров.
Необходимо на такой момент сделать автоматический перехват ошибок доступности капчи на беке и автоматическое переключение, в такиие моменты, на штатную битриксовую капчу при возникновении ошибок.

2.10. Наиболее частые ошибки

• Тестирование осуществлялось под администратором.
• Формы регистрации, авторизации, обратной связи и все прочие формы: если что-то введено неверно или НЕ введено обязательное поле – должна высвечиваться ошибка.
• В полях форм name, id и других атрибутах, недопустимо жестко прописывать id полей. На предпроде и на бою id будут различаться. В шаблонах надо динамически по коду поля получать id.
• Форма восстановления пароля должна работать корректно. Кнопка «Выход» должна быть и должна работать. После авторизации или регистрации мы должны возвращаться на ту же страницу, откуда пришли.
• 404 страница – должна быть, пусть даже в стандартном виде.
• Файл /robots.txt не закрыт на тестовом сайте или имеет не правильные ссылки на бою.
• Файл /sitemap.xml имеет ссылки на тестовую площадку, битые ссылки или ссылки, которые не должны находиться там.

3. Оценки на проектах

Перед стартом работ Тимлид в обязательном порядке оценивает (в часах) предстоящие работы.

4. Код-ревью на проектах

Код-ревью на проектах закреплен отдельным регламентом, который не противоречит общепринятыми правилами разработки.

5. Промежуточные тестирования и тестирования перед сдачей проекта

5.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix

В настройках главного модуля включены все галки /bitrix/admin/settings.php?lang=ru&mid=main:

• Объединять CSS файлы (включено).
• Объединять JS файлы (включено).
• Подключать минифицированные версии CSS и JS файлов (включено).
• Переместить весь Javascript в конец страницы (включено).
• Создавать сжатую копию объединенных CSS и JS файлов (включено).

В настройках кеширования должно быть включено /bitrix/admin/cache.php?lang=ru:

• Автокеширование компонентов (включено).
• Управляемый кеш компонентов (включено).

5.2. Тестирование общих настроек системы

• Ускорение сайта CDN – выключено (это в зависимости от проекта).
• Включен и настроен веб-антивирус (ВАЖНО! В качестве действия включать только оповещение, НЕ вырезание кода и не замену на безопасный код!).
• Отключаем модуль «Веб-Антивирус» — выключено (если это не противоречит ТЗ).
• Отключаем модуль «Веб-аналитика» (если он не используется на сайте согласно ТЗ).
• Проведен аудит сканером безопасности: /bitrix/admin/security_scanner.php при этом если ошибки в хостинге – необходимо оповестить об этом менеджера проекта через интранет (настройки хостинга не входят в задачи программирования).
• Настроены корректные e-mail адреса (администратора сайта и для уведомлений) — эти данные необходимо запросить у менеджера проекта.
• Шаблоны сайтов названы корректно и по ним (названию + описанию) понятно, зачем каждый шаблон. Не должно быть одинаково названных шаблонов. То же относится и к компонентам и к шаблонам компонентов.
• Модули «Документооборот» и «Веб-аналитика» - удалены, если не используются.
• Все иные модули, типа «Списки» — также удалены, если не используются.
• /robots.txt - правильно настроен.
• /sitemap.xml - имеет правильные ссылки.

5.3. Использование обезличенных данных при тестировании

Если в процессе тестирования делается заказ или регистрируется пользователь или заполняется формочка – обязательно в заказе/ФИО/форме писать «Тест», «Тестовый» и т.д.
При создании страниц и разделов необходимо указывать их заголовки. Например, если создаётся раздел сайта «Новости», то в свойствах раздела и страницы следует указать название «Новости».
ПРОВЕРКА: проверяем заголовки страниц сайта, чтобы не было ерунды и они не были пустыми.

5.4. Настройки пользователей пользователей для проведения тестирования

Пароль у главного администратора не должен быть простым.
ПРОВЕРКА: простой пароль – это «123123», пароль, равный адресу почты и т.д. При необходимости – сменить пароль самостоятельно, отписать в задачу.
Для синхронизации с 1С создается ОТДЕЛЬНЫЙ пользователь, по имени которого ясно, зачем он существует. ПРОВЕРКА: запросить менеджера, какой аккаунт используется для синхронизации с 1С.
Лишние пользователи к моменту сдачи проекта должны быть удалены.
ПРОВЕРКА: посмотреть, что по каждой группе, кроме «обычных» юзеров, есть не более 1 пользователя (учитывая, разумеется, пункт выше про 1С-пользователя).
Группы пользователей должны соответствовать ТЗ — лишние должны быть удалены.

5.5. Тестирование скорости работы сайта

При сдаче проекта должны быть включены критические настройки сайта - 3.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix.
Если ТЗ предусмотрен композит, то необходимо удостоверится, что он работает.
ПРОВЕРКА: в настройках – автокэширование. Композит – внизу любого композитного сайта должен висеть шильдик («Быстро с 1С-Битрикс»). Если он не висит, то композит не работает.
Работу композита нужно проверить установкой в браузер Chrome расширения "Bitrix Composite Notifier".

5.6. Проверка оптимизации запросов к БД

При сдаче проекта необходимо запустить отладку количества запросов к БД и объем используемого кеша.
В интернет-магазине на главной странице под кешем, если больше 20 запросов к БД, то нужно оптимизировать кеширование и сами запросы. Без кеша более 200 запросов считается уже много.
Избыточный кеш у компонента может так же тормозить проект, т.к. перед выводом система его парсит.
У каждого показатели запросов и использования кода могут разнится в зависимости от ситуации.
На картинке ниже мы видим, что можно отследить как общую статистику, так и статистику по каждому отдельному компоненту.

5.7. Проверка оптимизации изображений на сайте

На скорость работы сайта влияют не оптимизированные изображения. Разрешение изображения всегда должно быть не больше размера отведенного под него. Если это слайдер, то превьюшка также должна быть соответствующего разрешения.

5.7.1. Проверка общего размера страницы на сайте

Вес страницы может зависеть от размера изображений, видео, js и css файлов.
Пример проверки скорости загрузки и веса страницы.
Если общий вес страницы превышает 2 мегабайта (усредненное значение), в редких случаях за 5 и более, то изображения и скрипты не оптимизированы.

5.8. Проверка общей производительности разделов и скорости работы сайта штатными средствами bitrix и использовании JMeter. Обязательный минимум

5.8.1. Установка и настройка JMeter

Инструкция по установке — https://loadtestweb.info/2017/10/17/install-apache-jmeter/ . В офисе уже есть заряженный компьютер для нагрузочного тестирования. Если есть проблемы с установкой JMeter, то можно воспользоваться им (в том числе удаленно).

5.8.2. Подготовка сценария тестирования для JMeter

Пример запросов (для интернет-магазинов запросы должны содержать в том числе значения умного фильтра):

"GET /delivery/
"GET /pay/
"GET /exchange-and-return/
"GET /about/
"GET /offer/
"GET /catalog/
"GET /catalog/metallicheskie-kanaly/legkie-listovye-lotki-s3-combitech/
"GET /catalog/metallicheskie-kanaly/legkie-listovye-lotki-s3-combitech/lotok-perforirovannyy-50kh50-l3000/
"GET /catalog/molniezashchita-i-zazemlenie/
"GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/
"GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/?PAGEN_1=2
"GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/?PAGEN_1=4
"GET /catalog/metallicheskie-kanaly/provolochnye-lotki-f5-combitech/filter/price-base-from-56/section-is-%D0%B0%D0%BA%D1%81%D0%B5%D1%81%D1%81%D1%83%D0%B0%D1%80%D1%8B%20%D0%B4%D0%BB%D1%8F%20%D0%BC%D0%BE%D0%BD%D1%82%D0%B0%D0%B6%D0%B0/etim_ef000008-is-44/apply/
"GET /catalog/metallicheskie-kanaly/provolochnye-lotki-f5-combitech/filter/clear/apply/
"GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/soedinitel-prutok-polosa-57kh80-mm/
"GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/khomut-na-metallicheskie-truby-d20-80-mm/
"GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/

5.8.3. Запуск процесса тестирования

/bitrix/admin/perfmon_panel.php – в котором тестировать сайт в течение 5 и более минут, пройдясь за это время по всем основным страницам сайта по несколько раз. При обнаружении факта загрузки страницы более 2 секунд (в ТЗ будет указано более точное значение) необходимо внести изменения в код и оптимизировать такой код, либо обосновать время загрузки.
После того, как в битриксе нажали тестирование, необходимо в JMeter нажать старт.

5.8.4. Анализ данных производительности

/bitrix/admin/perfmon_panel.php .

5.9. Прохождение стандартных тестов bitrix мастера проверки системы

При сдаче проекта необходимо пройти и настроить все пункты из мастера:
/bitrix/admin/storeassist.php
ПРОВЕРКА: все пункты должны соответствовать ТЗ. Если что-то не указано в ТЗ – писать в протоколе тестирования.

5.10. Монитор качества: прохождение дополнительных тестов

Проходим следующие тесты:

• Интеграция дизайна и разработка.
  
• Интеграция дизайна.
  
• Цепочка навигации. Общие элементы.
  

Интеграция стандартных компонентов и модулей:

• Настроены стандартные модули.

 Интеграция собственных компонентов и модулей:

• Компоненты используют кэширование.
• Шаблоны компонентов – формируют верстку.
• Объемный PHP-код оформлен в виде модуля.
• Не используются вставки PHP-кода.

 Безопасность:

• Группам пользователей предоставлены минимально необходимые права.

5.11. Общие нюансы проверки всех сайтов

Главная страница должна иметь вменяемый Title (содержащий как минимум слова «Главная» и название компании; если применимо – скопировать его со старого сайта компании). То же относится к внутренним тестовым страницам ПРОВЕРКА: при необходимости уточнить адрес старого сайта у менеджера.
У инфоблоков title должен быть равен названию инфоблока (для главной страницы – например, «Все новости»), либо названию раздела (для раздела каталога), либо названию товара (для карточки товара).

5.12. Нюансы проверки работы интернет-магазина

Список товаров: должны быть предусмотрены ситуации, когда товара нет в наличии, или когда нет цены – или товар не показывается, или отображается иконка/заглушка.
Также в тестовых целях должны быть представлены (если есть в ТЗ): товар со старой ценой, акционной ценой, спецпредложение (шильдик в углу фотки товара или что-то подобное) – то есть все виды «спец» товаров.
Карточка товара: должны быть предусмотрены ситуации, когда какое-либо из полей не заполнено. Также не должно быть пустых вкладок (если в карточке товара есть вкладки).

6. Проверка работы системы после переноса сайта на бой

6.1. Проверка работы системы после переноса сайта на бой всех сайтов

После переноса сайта на бой необходимо пройти проверку системы и проверку тестирования конфигурации /bitrix/admin/site_checker.php?lang=ru. Ошибок и предупреждений не должно быть. Не забываем, что агенты должны выполняться на cron (в том числе периодические если уместно).
Для корректного переноса важно знать:

• Не переносить папку .git средствами bitrix.
• Не трогать папку .git.
• Если происходят какие-то переносы площадок, после переноса проверить работоспособность git.
• Нужно уточнять по возможности у клиента, что за изменения на бою.

Соблюдены все правила — 3.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix.

6.2. Проверка правильности настройки robots.txt и sitemap.xml на бою

Необходимо, что бы на бою был корректно настроен robots.txt и sitemap.xml сразу как заказчик даст отмашку открыть сайт для индексации поисковыми роботами. Можно уточнить у менеджера.

1. Перед началом работы

Мы работаем строго с GIT. Без GIT работа не производится.

2. Требования по настройке git

На общем хосте (main) должна быть включена ветка stage. Ветка master используется только для боевого хоста.
Использовать только \n для перехода на новую строку.
Проверьте, чтобы .gitignore был правильно настроен.
Пример настройки .gitignore:

/bitrix/
/bitrix
/upload/
/upload
/local/vendor/
/local/vendor
/web.config
/.htaccess
/robots.txt
/*.xml
*.swp
*.log
*.zip
*.tar
*.rar
*.gz

Если в .gitignore положили всю папку /bitrix, но нам нужно работать с каким-то шаблоном, то его можно вернуть в git при помощи: !/bitrix/templates/learning_10_0_0/
.gitignore может быть изменен и дополнен в зависимости от потребностей проекта.
В GIT не должны попадать отладочные скрипты, логи, медиафайлы регистрируемые в БД и др.
Все наработки проверяет тимлид / старший программист проекта. Уточнять главного программиста у менеджера. Разработчик не меняет в обход тимлида ветки master, stage, layout-master, layout-stage и ветки, созданные другими разработчиками. 1 разработчик - 1 хост. Если на проекте должно одновременно работать несколько разработчиков, то количество хостов на проекте должно быть равно количеству разработчиков + 1 (общий хост на который сливаются все изменения). За этим следит менеджер проекта, и ему надо сообщать, если требование не соблюдается.
Все наработки разработчика сначала вливаются в stage, затем в master. Ничего не вливается сразу в master. Все новые ветки для выполнения новых задач начинаются от текущего stage. Доставкой изменений на бой занимается тимлид на проекте или его старший программист проекта.

3. Про перенос наработок и деплоев

3.1. Обязательный слив всех наработок в репозиторий во ВТ и ЧТ

Во вторник и четверг обязательный слив всех наработок в удаленный репозиторий. Наработки сливаются по мере готовности и в обязательном порядке во ВТ и ЧТ, даже если не закончен блок. Ответственный за контроль - Тимлид. Исполнитель данного мероприятия - разработчик. Разработчик до 19:00 во вторник и четверг должен отправить все наработки в репозиторий. Тимлид, в зависимости от потребности проекта, может изменить частоту обязательных сливов в репозиторий. Сделать чаще. Реже нельзя. Если нет дополнительных требований от тимлида, то обязательные сливы в репозиторий во вторник и четверг. За нарушение данного требования будет произведено депремирование. Если между дедлайнами сливов был непрерывный простой, то данное требование не работает.

3.2. Деплои на бой

Дни для деплоя - Пн, Вт, Ср, Чт с 10:00 до 16:00. Пт с 10:00 - 15:00. Исключения возможны только при выполнении срочных задач и по согласованию с менеджером проекта.

4. Создание и актуализация новой ветки перед выполнения новой задачи

Правила именования веток описаны в пункте 6. Актуализируем локальную ветку stage из удаленного репозитория. Cоздаем локальную ветку для разработки от stage.

5. Отчет о проделанной работе и подготовка к переносу наработок на предпрод для проверки

После выполнения наработок необходимо сделать git pull ... в текущую ветку из ветки stage удаленного основного репозитория и тем самым предотвратить появление конфликтов.
Пушим ветку с наработками git push ... в свою же ветку удаленного репозитория.
В удаленном репозитории создаем мерж реквест в stage на тимлида или старшему на проекте, если он отвечает за сливания.
Прикладываем в пункт чек-листа или в комментарии к задаче, если его нет, ссылку на merge request с наработкой и комментарием, что это за наработка.
Отписываемся тимлиду или старшему на проекте, если он отвечает за сливания, чтобы проверил работу и принял merge request, либо отправил на доработку.
Если всё ок, то смотрим работу на тестовой площадке.
Проверка наработок осуществляется только на тестовой площадке main!
Примечание: по усмотрению тимлида проекта актуализация ветки может производиться от ветки master, а не stage.

6. Правила переноса наработок на бой

Если выполненную задачу нужно переносить на бой:
Необходимо сделать git pull ... из ветки master удаленного основного репозитория и тем самым предотвратить появление конфликтов.
Создаём новый merge request, только вливаем уже в master.
Прикладываем в пункт чек-листа или в комментарии к задаче, если его нет, ссылку на merge request с наработкой и комментарием, что это за наработка.
Также отписываемся тимлиду или старшему на проекте, если он отвечает за сливания, который всё это ещё раз проверяет, принимает изменения (тимлид и менеджер) и вытягивает изменения на бою.
Проверяем функционал на бою.
Для корректного переноса важно знать:

• Не переносить папку .git средставими bitrix.
• Не трогать папку .git.
• Если происходят какие-то переносы площадок, после переноса проверить работоспособность git.
• Нужно уточнять по возможности у клиента, что за изменения на бою.

7. Правила именования веток

7.1. Правильное название ветки

7.1.1. Если чек-листы большие

Название веток должны содержать номер задачи и чек-лист, в рамках которой выполняется работа и пункт чек-листа.
То есть при выполнении задачи, ветка будет выглядеть следующим образом:
ih/номерЗадачи-ЧекЛист/краткоеОписаниеЗадачи

• Ih - значит inhouse, т.е. штатный сотрудник.
• os - outstaff - подрядчик.
• номерЗадачи - обязательно указываем номер задачи.
• ЧекЛист - обязательно указываем номер чек-листа.
• краткоеОписаниеЗадачи — это 2 - 4 слова.

 Пример правильно названной ветки:
ih/54361-3/updateCatalogStyles
В ветках важно в коммитах писать номера задач и чек-листов:
git commit -m "task-22333, buglist-1,2"

7.1.2. Если чек-листы маленькие и эти чек-листы не надо по отдельности переносить

Название веток должны содержать номер задачи.
То есть при выполнении задачи, ветка будет выглядеть следующим образом:
ih/номерЗадачи/краткоеОписаниеЗадачи

• Ih - значит inhouse, т.е. штатный сотрудник.
• os - outstaff - подрядчик.
• номерЗадачи - обязательно указываем номер задачи.
• краткоеОписаниеЗадачи — это 2 - 4 слова.

Пример правильно названной ветки:
ih/54361/updateCatalogStyles
В ветках важно в коммитах писать номера задач и чек-листов
git commit -m "task-22333, buglist-1,2"

7.2. Название ветки с багами

7.2.1. Название ветки с багами одного пункта чек-листа

ih/54361-3/bugFix

7.2.2. Название ветки с багами всей задачи

#Данная ветка используется при массовой починке багов
ih/54361/bugFix

7.3. Предельная ситуация при названии ветки

В случае, если работа по какой-то причине не привязана к конкретной задаче, именование следующее:
ih/годмесяц/краткоеОписаниеЗадачи
Пример альтернативно названной ветки если нет задачи под неё:
ih/2107/checkoutRefactoring

8. Правила именования коммитов

Именование коммита должно отражать суть проделанной работы.
В именовании коммита должен присутствовать номер задачи и номер пункта данной задачи.
Пример: "54361-1 import elements to offers iblock" Где 54361-1 номер задачи и через тире номер пункта.

9. Если редактируемый файл не правильно отформатирован (PSR, переносы)

Если вам приходится работать с существующим кодом в файле и данный код не правильно отформатирован, то если мы сделаем доработку и отформатируем весь код файла, в коммите будет непонятно, что именно изменилось.
Для того, что бы предотвратить данную проблему, необходимо:

• Перед выполнением работ отформатировать данный файл, согласно регламенту написания кода (в PHPStorm можно комбинацией клавиш [CTRL] + [ALT] + L) и закоммитить, при этом в настройках PHPStorm должны стоять верные настройки PSR и версия PHP. В коммите указать, что это форматирование.
• Начать выполнять работу только после коммита с форматированием.

10. Работа с версткой и стилями

Бэкендер не правит прямо в back-end ветке стили или вёрстку. Для работы с версткой используется отдельный репозиторий. Соблюдение правил работы со сборщиками.

11. Уточнения к правилам переноса правок на бой (частный случай к пункту 5)

Новая ветка должна актуализироваться каждый раз пред выполнением и в нее из ветки предпрода может подтянуться то, что еще нельзя переносить.
Т.к. в данном проекте ожидается большая очередь переноса правок на бой и продолжительное время приемки нового функционала из разных блоков, необходимо:

• В выполненном пункте задачи должны быть перечислены все коммиты (хеши), которые к нему относятся.
• Осуществлять перенос целыми блоками на бой (логически завершенными блоками), а не отдельными его частями, чтобы предотвратить появление конфликтов и багов из-за пересечений в коммитах.
• Перенос надо осуществлять релизными ветками вида: release/20210408 где 20210408 — сегодняшняя дата.
• В релизную ветку наработки надо переносить командой: git cherry-pick коммит.

Надо находиться в ветке, в которую хотите перенести коммит командой git cherry-pick коммит.
Если переносимого коммита нет в вашем локальном git, то надо сперва подтянуть изменения из других веток к себе в гит (команда в вашу ветку из других веток ни чего не вольёт) git fetch origin git fetch - забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

12. Команды, полезные тимлиду

12.1 Команда, что бы добавить новые изменения в последний коммит

Команда полезная, но не простая. После этого не получится push изменения в репозиторой. Сперва придется сделать pull и решить конфликты в добавленном файле

git add file 
git commit --amend --no-edit

13. Иное

Во всех непонятных ситуациях необходимо обратиться за помощью к документации на первоисточника GIT. Если решение не нашлось, необходимо обратится за помощью к коллегам (программистам, тимлиду).

Проверка (экспертиза) эксплуатационной документации от вендора, сообщества на наличие информации о поддержке и обновлениях, включая устранение уязвимостей.

Идентификация и аутентификация

Для идентификации пользователей при доступе каждому пользователю должен быть назначен уникальный персональный идентификатор.

Доступ пользователей должен осуществляться посредством парольной аутентификации.

Должна обеспечиваться защита обратной связи при вводе аутентификационной информации.

Локальная парольная политика должна удовлетворять требованиям:

• политика сложности пароля;

• хранение истории паролей;

• установка срока действия пароля;

• возможность смены пароля при первом входе;

• возможность самостоятельной смены пароля

Возможность интеграции с системой управления идентификационными данными.

Авторизация пользователей на доступ должна производиться только после прохождения процедур идентификации и аутентификации.

Поддержка механизмов многофакторной аутентификации.

Управление доступом.

Управление доступом

Регистрация и учет событий ИБ

• регистрацию даты и времени входа/выхода, попытки входа пользователя;

• регистрацию даты и времени запуска/остановки компонент;

• регистрацию изменения полномочий пользователей;

• регистрацию изменения настроек;

• регистрацию действий администраторов;

• регистрацию действий пользователей

Защита программного обеспечения

Обеспечение целостности

Сетевая безопасность

Криптографическая защита

Контроль НДВ