Кожна команда DevOps стикалася з випадками, коли, наприклад, пакет програмного забезпечення, необхідний для створення або розгортання програми, був не там, де він мав би бути, коли потрібно. У таких випадках виникають додаткові затримки, яких можна було уникнути, повідомляє DevOps.com.
На щастя, організації починають усвідомлювати, що інструменти, які використовуються для створення та розгортання програмного забезпечення, створюють метадані, які можна відстежувати, а також використовувати для оптимізації робочих процесів.
Наприклад, TestifySec’s Witness – інструмент із відкритим вихідним кодом для створення та перевірки атестацій. Він забезпечує перевірений запис кроків, зроблених для створення програмного забезпечення, включно з використаними матеріалами та командами, які виконуються під час робочого процесу DevOps.
Супутній проєкт Archivista із відкритим вихідним кодом керує зберіганням, пошуком і збереженням атестацій конвеєрів збірки програмного забезпечення та довіреної телеметрії, яку спостерігає Witness.
Ці та інші інструменти перебувають в авангарді ширших зусиль із використання вже створених інструментів для створення програмного забезпечення метаданих таким чином, щоб не лише забезпечити виконання завдань, але й зробити ланцюг постачання програмного забезпечення більш безпечним.
«Щоб ефективно покращити безпеку ланцюга постачання програмного забезпечення, важливо навмисне спостерігати за робочими процесами DevOps, а не сподіватися реконструювати дані з робочих процесів після факту», – сказав Мітч Ешлі, головний аналітик Techstrong Research.
Оскільки правила, які вимагають від організацій керувати ланцюгами постачання програмного забезпечення, стають все більш жорсткими, тепер лише питання часу, коли групи відповідності вимагатимуть від команд розробників програмного забезпечення документувати кожну взаємодію, яка мала місце протягом усього життєвого циклу розробки програмного забезпечення (SDLC).
Виклик документації DevOps
Команди DevOps сьогодні регулярно використовують численні інструменти для створення артефактів програмного забезпечення, керування конвеєрами розробки програмного забезпечення та, зрештою, розгортання програмного забезпечення.
Рівень зрілості DevOps значно відрізнятиметься від однієї організації до іншої, але всі вони мають одну спільну рису: керівник проєкту намагається відстежувати взаємодію між цими інструментами, щоб забезпечити дотримання графіків доставки програм.
Однак керівники проєктів змушені покладатися на введення даних вручну, щоб зафіксувати ці взаємодії таким чином, щоб їх можна було використовувати для перевірки виконання завдання. В ідеальному світі самі інструменти автоматично обмінюватимуться необхідними даними із програмою, що спрощує визначення того, які завдання фактично виконано.
За відсутності такого рівня автоматизації не дивно, що проєкти затримуються просто тому, що те чи інше критичне завдання не було виконано вчасно, щоб наступний етап процесу розробки програмного забезпечення не міг початися вчасно. Затримки, яких можна було уникнути, мають каскадний вплив протягом усього життєвого циклу розробки ПЗ.
Команди розробників часто бувають у розгубленості, коли настає час пояснити бізнес- та ІТ-лідерам, що пішло не так, тому що немає способу визначити, що саме та коли сталося під час процесу розробки програмного забезпечення.
Виклик відповідності
Оскільки проблеми з безпекою ланцюга постачання ПЗ продовжують зростати, все більше організацій вимагають документувати робочі процеси розробки ПЗ, які використовувалися для створення певних програм. У разі проведення аудиту будь-яка неможливість надати цю документацію лише збільшить розмір штрафів.
Чим складнішими стають програми, що розгортаються, тим більша ймовірність того, що критична подія, на якій проводиться аудит, не буде зафіксована через людські помилки. На жаль, більшість ІТ-лідерів уже добре знають, що у тому, що стосується відповідності вимогам, людські слабкості не можна пробачити.
Автоматизація
Як це майже завжди буває, коли справа доходить до робочих процесів DevOps, найкращим шляхом є підвищена автоматизація.
Одна з головних причин, чому більшість цих робочих процесів недостатньо добре задокументована, полягає в тому, що люди загалом і розробники застосунків зокрема не надто люблять введення даних. Ніхто не хоче витрачати час на введення даних, які вже знаходяться в іншій програмі.
Окрім втрати часу, існує також висока ймовірність виникнення помилок, оскільки дані вручну копіюються з однієї програми в іншу.
ІТ-лідери сподіваються, що всі завдання, які потрібно виконати, щоб забезпечити вчасну доставку програми, дійсно виконано. Однак надія не замінить платформу, яка автоматично фіксує, аналізує та підтверджує кожен крок, який стався для визначення фактичного наміру, а не просто подає серію журналів, які не надають достатньо значущого контексту.
Висновки
Повільно, але впевнено процеси, на які організації покладаються для керування програмним забезпеченням, стають все більш досконалими.
Можливості, які кілька років тому здавалися надто складними для надання, тепер легко доступні. Збирання метаданих у спосіб, який дозволяє організаціям автоматизувати робочі процеси у безпрецедентних масштабах, стає все більш звичним явищем.
Виклик і можливість тепер полягають у пошуку найпростіших можливих засобів, щоб використовувати його в той час, коли середовища застосування стають надто складними, щоб керувати ними іншим чином.
Читайте також на ProIT: Машинне навчання у прогнозному тестуванні для середовищ DevOps.
Також ProIT повідомляв про захист конвеєра DevOps: інструменти та найкращі практики.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
