Політика управління змінами
ISMS Copilot дотримується формальної політики управління змінами, щоб гарантувати, що всі зміни у виробничих системах перевіряються, тестуються та безпечно впроваджуються. Наш процес поєднує вимоги безпеки та відповідності зі швидким ітеративним розвитком.
ISMS Copilot дотримується формальної політики управління змінами, щоб гарантувати, що всі зміни у виробничих системах перевіряються, тестуються та безпечно впроваджуються. Наш процес поєднує вимоги безпеки та відповідності зі швидким ітеративним розвитком.
Наша політика управління змінами інтегрована безпосередньо з робочим процесом GitHub та CI/CD-конвеєром для автоматичного контролю.
Типи змін
Ми класифікуємо зміни на три типи залежно від ризику та впливу:
- Стандартні зміни — Зміни з низьким рівнем ризику, попередньо схвалені, такі як оновлення документації, патчі залежностей та рутинні оновлення конфігурацій. Вони можуть автоматично зливатися після проходження автоматизованих перевірок.
- Звичайні зміни — Додавання функцій, модифікації схеми бази даних, зміни API та оновлення безпеки. Вимагають повного процесу перевірки з принаймні одним схваленням перед впровадженням.
- Екстрені зміни — Критичні уразливості безпеки, збої в роботі сервісів або проблеми з цілісністю даних. Вимагають прискореного процесу схвалення, зберігаючи при цьому журнал аудиту та проведення перевірки після впровадження.
Процес схвалення
Наш стандартний процес внесення змін включає такі етапи:
- Створення Issue у GitHub — Запит на зміну документується з обґрунтуванням та оцінкою впливу
- Гілка та Pull Request — Зміни в коді розробляються у функціональній гілці з детальним PR
- Автоматизоване тестування — CI-конвеєр запускає автоматизовані тести, включаючи юніт-тести, інтеграційні тести та сканування безпеки
- Рев’ю колегою — Принаймні один член команди перевіряє код, архітектуру та наслідки для безпеки
- Схвалення та злиття — Схвалені зміни зливаються в основну гілку
- Автоматичне впровадження — Зміни автоматично впроваджуються у виробництво через наш CI/CD-конвеєр (Supabase, Fly.io, Vercel)
Екстрені зміни проходять прискорений процес, але все одно зберігають журнал аудиту та вимагають перевірки після впровадження протягом 24 годин.
Тестування та контроль якості
Перш ніж будь-яка зміна потрапить у виробництво, наш автоматизований CI-конвеєр забезпечує:
- Виконання автоматизованого набору тестів
- Валідацію міграцій бази даних у середовищі Supabase CI
- Статичний аналіз коду та сканування безпеки
- Перевірку збірки для всіх цілей впровадження
Відкат та відновлення
Наша політика управління змінами включає процедури відкату для невдалих впроваджень. Ми зберігаємо можливість швидко повернути зміни, зберігаючи цілісність даних та доступність системи.
Усі зміни відстежуються в GitHub з повним журналом аудиту, включаючи осіб, які схвалили зміни, часові мітки та обґрунтування змін.
Управління секретами та конфігурацією
Зміни, що стосуються секретів, ключів API або чутливої конфігурації, підлягають додатковим заходам безпеки, окрім стандартних процедур внесення змін, щоб запобігти витоку облікових даних.