One place for hosting & domains

      Введение в лучшие практики CI/CD


      Введение

      Методика непрерывной интеграции, доставки и развертывания (CI/CD) — неотъемлемая часть современного процесса разработки, призванная снизить количество ошибок во время интеграции и развертывания и повысить скорость реализации проектов. CI/CD — это одновременно философия и набор практик, которые часто усиливваются высоконадежными инструментами, обеспечивающими автоматическое тестирование на каждом шаге конвейера программного обеспечения. Добавляя их в свою практику, вы можете сократить затраты времени на интеграцию изменений в новом выпуске и тщательно тестировать каждое изменение перед переносом в производственную среду.

      CI/CD имеет множество потенциальных преимуществ, однако для успешной реализации часто требуется тщательный анализ. Принятие точного решения относительно использования инструментов и необходимых изменений в среде может оказаться непростой задачей, если не прибегать к методу проб и ошибок. Однако хотя разные виды реализации будут различаться, лучшие практики помогут вам избежать распространенных проблем и быстрее совершенствовать свою среду.

      В этом обучающем модуле содержатся базовые указания по внедрению и поддержке системы CI/CD для оптимального соответствия потребностям вашей организации. Мы расскажем о ряде практик, которые помогут повысить эффективность вашей службы CI/CD. Вы можете прочитать этот материал целиком или сразу перейти к интересующим вас разделах.

      Поддержание высокой скорости конвейеров

      Конвейеры CI/CD помогают внедрять изменения в рамках автоматизированных циклов тестирования, в том числе в тестовых и производственных средах Чем больше процедур охватывают ваши конвейеры тестирования, тем надежнее гарантия отсутствия побочных эффектов изменений при развертывании в производственной среде. Однако поскольку данную процедуру следует применять для всех изменений, быстрота и надежность конвейера очень важны для сохранения скорости разработки.

      Возможно баланс между этими двумя требованиями не так просто достичь. Вы можете предпринять ряд простых шагов для повышения скорости работы, включая масштабирование инфраструктуры CI/CD и оптимизацию тестирования. Однако с течением времени у вас может возникнуть необходимость принимать критически важные решения касательно относительной ценности разных тестов и этапа или порядка их выполнения. Иногда для сохранения требуемой скорости процессов лучше всего удалить из набора тестов некоторые компоненты, имеющие наименьшую ценность или дающие плохо интерпретируемые результаты.

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

      Изоляция и защита среды CI/CD

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

      Системы CI/CD следует развертывать во внутренних защищенных сетях без возможности внешнего доступа. Рекомендуется настроить VPN и другие технологии контроля доступа к сети, чтобы ваша система была доступна только прошедшим аутентификацию операторам. В зависимости от сложности топологии вашей сети, вашей системе CI/CD может потребоваться доступ к разным сетям для развертывания кода в разнообразных средах. Если сети не будут надлежащим образом защищены или изолированы, злоумышленники с доступом к одной среде могут использовать этот доступ для эксплуатации уязвимостей внутренних сетей с целью получения доступа к другим серверам через слабые места серверов CI/CD.

      Требуемые стратегии изоляции и защиты зависят от топологии сети, инфраструктуры и требований к управлению и разработке. Очень важно помнить, что ваши системы CI/CD представляют собой очень важные цели для злоумышленников, поскольку они часто имеют высокий уровень доступа к другим критически важным системам. Защита внешнего доступа к серверам и жесткий контроль внутреннего доступа помогут снизить риск взлома вашей системы CI/CD.

      Прекращение конвейера CI/CD в единственный способ развертывания в производственной среде

      Инструменты для внедрения передовых практик тестирования и развертывания также помогают системам CI/CD оптимизировать процесс разработки и повысить качество кода. Для распространения кода через конвейеры CI/CD необходимо сделать так, чтобы каждое изменение соответствовало кодифицированным стандартам и процедурам вашей организации. Любые неисправности конвейера CI/CD сразу же становятся заметными, и при их возникновении процесс разработки новых версий останавливается на последующих этапах цикла. Такой механизм защищает важные среды от ненадежного кода.

      Для использования этих преимуществ требуется внедрить надлежащую производственную дисциплину, чтобы все изменения рабочей среды проходили через ваш конвейер. Конвейер CI/CD должен быть единственным механизмом поступления кода в производственную среду. Это может делаться автоматически в конце успешного тестирования с применением практик непрерывной разработки, а также посредством ручного распространения протестированных изменений, одобренных и опубликованных через систему CI/CD.

      Очень часто команды разработчиков используют конвейеры для развертывания, но при этом допускают исключения при возникновении проблем и необходимости их срочного решения. Хотя простои и другие проблемы необходимо устранять как можно скорее, при этом очень важно понимать, что система CI/CD обеспечивает отсутствие ошибок, новых неисправностей и других побочных эффектов при внедрении изменений. Развертывание исправлений через конвейер (или просто использование системы CI/CD для отката) также предотвращает удаление напрямую установленных исправлений при развертывании следующих версий. Конвейер защищает целостность как плановых обновлений, так и экстренных обновлений, призванных устранить текущие проблемы. Такое использование системы CI/CD также дает еще одну причину обеспечить максимальное быстродействие конвейера.

      Сохранение соответствия с производственной средой по мере возможности

      Конвейеры CI/CD используются для развертывания изменений через тестовые комплекты и среды развертывания. Изменения, проходящие проверку на соответствие требованиям на одном этапе, автоматически развертываются или помещаются в очередь ручного развертывания для сред с более высокими требованиями. Ранние этапы тестирования призваны подтвердить ценность тестирования и внедрения изменений на уровнях, находящихся ближе к производственной среде.

      На более поздних этапах воспроизведение производственной среды в тестовых средах обеспечивает более точное соответствие тестов реальной реакции производственной среды на изменения. При значительных отличиях между тестовыми и производственными средами существует вероятность возникновения при развертывании проблем, которые не наблюдались при тестировании. Чем больше будет заметно отличий между рабочей средой и тестовой средой, тем меньше уверенности в стабильной работе приложений дают тесты.

      Небольшие отличия между тестовыми и производственными средами закономерны, но их необходимо контролировать и хорошо понимать. Некоторые организации используют схему развертывания «синий-зеленый» для переключения производственного трафика межжду двумя практически идентичными средами, которые по очереди выполняют функции рабочей и тестовой среды. Менее экстремальные стратегии предусматривают использование в тестовой среде той же конфигурации, что и в рабочей среде. но в уменьшенном масштабе. Конечные точки сети и другие подобные элементы разных сред могут отличаться, однако параметризация такого типа переменных данных поможет обеспечить единообразие кода и четкое определение отличий разных сред.

      Выполните только одну сборку и разверните результаты через конвейер

      Основная цель конвейера CI/CD — обеспечить уверенность в изменениях и минимизировать вероятность непредвиденного негативного воздействия. Мы обсудили важность поддержания соответствия сред, однако один компонент такого соответствия заслуживает особого внимания. Если для вашего программного обеспечения требуется этап сборки, упаковки или объединения в комплект, этот этап должен выполняться только один раз, и его результат должен многократно использоваться в масштабах всего конвейера.

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

      Для предотвращения этой проблемы в системы CI должен быть включен процесс сборки на первом этапе конвейера, предусматривающий создание и упаковку программного обеспечения в чистой среде. Полученную сборку с присвоенным номером версии следует выгрузить в хранилище артефактов, откуда она будет извлекаться на следующих частях конвейера. Это гарантирует, что на разных участках системы будет использоваться одна и та же сборка.

      Самые быстрые тесты следует проводить заранее

      Хотя быстрая работа конвейера в целом очень важна, некоторые части комплекса тестирования будут неизбежно выполняться быстрее других. Поскольку система CI/CD обрабатывает все изменения в системе, очень важно как можно раньше обнаруживать любые неполадки, чтобы минимизировать выделение ресурсов на проблемные варианты сборки. Для этого желательно в приоритетном порядке выполнять самые быстрые тесты. Сложные и длительные тесты лучше отложить до тех пор, пока вы не проверите сборку с помощью небольших и быстрых тестов.

      Такая стратегия дает ряд преимуществ, помогающих оптимизировать процесс CI/CD. Она помогает лучше понять влияние отдельных тестов на производительность, быстро выполнять основную часть тестов и раньше выявлять неполадки, что позволит отменить проблемные изменения или внести исправления, до того, как неполадки скажутся на работе.

      Приоритетное тестирование подразумевает первоочередное выполнение тестов проектного компонента, поскольку эти тесты обычно быстрые, изолированные и ориентированы на конкретные элементы. Тесты интеграции идут следующими по скорости и сложности, затем идут системные тесты, а на последнем этапе идут приемочные испытания, в которых обычно принимают участие операторы.

      Минимизируйте ветвление в системе управления версиями

      Один из главных принципов CI/CD — быстро и часто интегрировать любые изменения в главное общее хранилище. Это помогает избежать дорогостоящих проблем с интеграцией на поздних этапах, когда разные разработчики записывают большие, разнородные и даже конфликтующие друг с другом пакеты изменений в главное хранилище непосредственно перед выпуском. Обычно системы CI/CD настраиваются для мониторинга и тестирования изменений, влияющих на одно или несколько ответвлений проекта.

      Чтобы использовать все преимущества CI в полной мере. лучше всего ограничить количество и состав ответвлений в вашем хранилище. В большинстве вариантов реализации предполагается, что разработчики будут записывать изменения непосредственно в главное хранилище или хотя бы раз в день синхронизировать его с локальными ответвлениями.

      Ответвления, которые не отслеживаются системой CI/CD, содержат непроверенный код, и должны рассматриваться как риск для успеха и скорости выполнения проекта. Минимизация ответвлений для быстрой интеграции кода разных разработчиков помогает использовать сильные стороны системы и не дает разработчикам аннулировать ее преимущества.

      Локальное выполнение тестов до отправки в конвейер CI/CD

      Продолжая вышесказанное, также разработчикам рекомендуется выполнять как можно больше тестов на локальном уровне, прежде чем записывать изменения кода в общее хранилище. Это позволяет обнаруживать определенные проблемные изменения до того, как они начнут мешать работе других членов команды. Хотя в локальной среде разработки вряд ли можно будет выполнить полный набор тестов, такой же как в производственной среде, этот дополнительный шаг дает разработчикам уверенность, что их код соответствует требованиям базовых тестов, и его стоит интегрировать в основную базу кода.

      Чтобы разработчики могли эффективно выполнять тестирование самостоятельно, набор тестов должен запускаться с помощью одной команды из любой среды. Та же самая команда, которую будут использовать разработчики на своих локальных компьютерах, должна использоваться системой CI/CD для запуска тестов кода в хранилище. Обычно для координации используется скрипт оболочки или файл makefile, которые автоматизируют инструменты тестирования, помогая получать воспроизводимые и прогнозируемые результаты.

      Выполнение тестов в абстрагированных средах, если это возможно

      Чтобы все тесты на разных этапах выполнялись одинаково, имеет смысл использовать чистые абстрагированные среды тестирования, если это возможно. Обычно это означает, что тесты выполняются в контейнеров для абстрагирования разницы между системами хоста и предоставления стандартного API для объединения компонентов в различных масштабах. Поскольку контейнеры работают с минимальным состоянием, побочные эффекты тестирования не воспроизводятся при последующих запусках набора тестов, что могло бы исказить результаты.

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

      Заключение

      Хотя разные виды реализации CI/CD могут различаться, следование некоторым из этих базовых принципов поможет избежать распространенных проблем и оптимизировать практики тестирования и разработки. Непрерывная интеграция и сочетание процессов, инструментов и правил работы помогут сделать изменения в разработке более успешными и эффективными.

      Чтобы узнать больше об общих практиках CI/CD и о настройке различных служб CI/CD, читайте другие статьи с пометкой CI/CD.



      Source link

      Introducción a prácticas recomendadas de CI/CD


      Introducción

      La integración, entrega e implementación continuas, conocidas en conjunto como CI/CD, son una parte integral del desarrollo moderno que pretende reducir los errores durante la integración y la implementación mientras se aumenta la velocidad del proyecto. CI/CD es una filosofía y un conjunto de prácticas a menudo aumentadas por herramientas sólidas que enfatizan las pruebas automatizadas en cada etapa del proceso de software. Al incorporar estas ideas en su práctica, puede reducir el tiempo necesario para integrar los cambios para una versión y probar en profundidad cada cambio antes de pasar a la producción.

      La CI/CD tiene muchos beneficios potenciales, pero para una implementación exitosa a menudo se requiere mucho análisis. Sin un método de ensayo y error exhaustivo, definir exactamente la forma de usar las herramientas y los cambios que puede necesitar en sus entornos o procesos puede ser un desafío. Sin embargo, aunque todas las implementaciones son diferentes, ceñirse a las mejores prácticas puede servirle para evitar problemas comunes y lograr mejoras de manera más rápida.

      En esta guía, presentaremos algunas pautas básicas sobre cómo implementar y mantener un sistema de CI/CD para satisfacer mejor las necesidades de su organización. Abarcaremos varias prácticas que le servirán para mejorar la efectividad de su servicio de CI/CD. No dude en leer el documento completo o ir directamente a las áreas que le interesen.

      Procure que sus procesos sean rápidos

      Los procesos de CI/CD ayudan a guiar los cambios a través de ciclos de prueba automatizados, hacia entornos de ensayo y, finalmente, hacia la producción. Cuanto más completos sean sus procesos de prueba, mayor será la garantía de que los cambios no introducirán efectos secundarios imprevistos en su implementación de producción. Sin embargo, dado que cada cambio debe pasar por este proceso, preservar la velocidad y confiabilidad de sus procesos es increíblemente importante para no inhibir la velocidad de desarrollo.

      Equilibrar la tensión entre estos dos requisitos puede ser difícil. Hay algunos pasos sencillos que puede seguir para mejorar la velocidad; por ejemplo, ampliar su infraestructura de CI/CD y optimizar las pruebas. Sin embargo, con el paso del tiempo, puede verse obligado a tomar decisiones críticas sobre el valor relativo de las diferentes pruebas y la etapa o el orden en que se ejecutan. A veces, reducir el conjunto de pruebas eliminando las pruebas de bajo valor o con conclusiones indeterminadas es la forma más inteligente de mantener la velocidad requerida por procesos muy utilizados.

      Al tomar estas decisiones significativas, asegúrese de entender y documentar las compensaciones que realice. Consulte a miembros del equipo y a partes interesadas para alinear las suposiciones del equipo respecto de lo que se espera del conjunto de pruebas y de cuáles deben ser las áreas de enfoque principales.

      Aísle y proteja su entorno de CI/CD

      Desde el punto de vista de la seguridad operativa, su sistema de CI/CD representa una de las infraestructuras que con mayor empeño se deben proteger. Dado que el sistema de CI/CD tiene acceso completo a su base de códigos y credenciales para la implementación en varios entornos, es esencial protegerlo para cuidar los datos internos y garantizar la integridad de su sitio o producto. Debido a su alto valor como objetivo, es importante aislar y bloquear su CI/CD todo lo posible.

      Los sistemas de CI/CD deben implementarse en redes internas protegidas, sin exposición a terceros. Se recomienda configurar de VPN u otra tecnología de control de acceso a la red para garantizar que solo los operadores autenticados puedan acceder a su sistema. Según la complejidad de la topología de su red, su sistema de CI/CD puede necesitar acceder a varias redes diferentes para implementar código en diferentes entornos. Si no cuenta con la protección o el aislamiento correspondiente, los atacantes que obtengan acceso a un entorno pueden ser capaces de practicar saltos de un punto a otro, una técnica utilizada para ampliar el acceso aprovechando las reglas de red internas más indulgentes, a fin de obtener acceso a otros entornos a través de los puntos débiles de sus servidores CI/CD.

      Las estrategias de aislamiento y seguridad requeridas dependerán en gran medida de la topología e infraestructura de su red y de sus requisitos de administración y desarrollo. El punto importante que se debe tener en cuenta es que sus sistemas de CI/CD son objetivos muy valiosos y, en muchos casos, tienen un amplio grado de acceso a sus otros sistemas esenciales. Blindar todos los accesos externos a los servidores y controlar de forma estricta los tipos de acceso interno permitidos ayudarán a reducir el riesgo de que su sistema de CI/CD se vea comprometido.

      Haga que el proceso de CI/CD sea la única forma de realizar implementaciones en la producción

      Parte de lo que hace posible que CI/CD mejore sus prácticas de desarrollo y la calidad de su código es que las herramientas a menudo permiten aplicar las prácticas recomendadas para la prueba y la implementación. La promoción del código a través de sus procesos de CI/CD requiere que cada cambio demuestre que cumple con los estándares y procedimientos codificados de su organización. Las fallas en un proceso de CI/CD se pueden ver de inmediato y detienen el avance de la versión afectada hasta etapas posteriores del ciclo. Este es un mecanismo de control de acceso que protege los entornos más importantes contra códigos no confiables.

      Sin embargo, para obtener estas ventajas es necesario ser disciplinado a fin de garantizar que cada cambio en su entorno de producción pase por su proceso. El proceso de CI/CD debería ser el único mecanismo por el cual el código ingresa en el entorno de producción. Esto puede suceder automáticamente al final de las pruebas exitosas con prácticas de implementación continua o mediante una promoción manual de cambios probados aprobados y puestos a disposición por su sistema de CI/CD.

      Con frecuencia, los equipos comienzan a utilizar sus procesos para la implementación, pero empiezan a hacer excepciones cuando se producen problemas y hay presión para resolverlos rápidamente. Si bien es necesario resolver problemas como el tiempo de inactividad y otros lo más pronto posible, es importante entender que el sistema de CI/CD es una buena herramienta para garantizar que sus cambios no introduzcan otros errores ni generen aún más daños en el sistema. Poner su solución mediante el proceso (o simplemente usar el sistema de CI/CD para retroceder) también evitará que en la próxima implementación se borre una corrección ad hoc aplicada directamente a la producción. El proceso protege la validez de sus implementaciones, independientemente de si se trata de una versión regular y planificada o una solución rápida para resolver un problema en curso. Este uso del sistema de CI/CD es otra razón más para procurar que su proceso sea rápido.

      Mantenga la paridad con la producción siempre que sea posible

      Los procesos de CI/CD promueven cambios mediante una serie de conjuntos de pruebas y entornos de implementación. Los cambios que superan los requisitos de una etapa se implementan automáticamente o se ponen en cola para su implementación manual en entornos más restrictivos. Las primeras etapas tienen por objeto demostrar que vale la pena seguir probando e impulsando los cambios más cerca de la producción.

      En particular para las etapas posteriores, reproducir el entorno de producción de la manera más fidedigna posible en los entornos de pruebas ayuda a garantizar que estas últimas reflejen con precisión el comportamiento que tendría el cambio en la producción. Las diferencias significativas entre la puesta en escena y la producción pueden permitir que se liberen cambios problemáticos que nunca se observaron en las pruebas. Cuantas más diferencias haya entre su entorno activo y el entorno de pruebas, menos medirán sus pruebas el comportamiento que tendrá el código cuando se libere.

      Se esperan algunas diferencias entre la puesta en escena y la producción, pero es esencial procurar que sean manejables y asegurarse de que se comprendan bien. Algunas organizaciones utilizan implementaciones “blue-green” para intercambiar el tráfico de producción entre dos entornos casi idénticos cuyas designaciones se alternan entre la producción y la puesta en escena. Estrategias menos extremas implican la implementación de la misma configuración e infraestructura desde la producción hasta su entorno de puesta en escena, pero a una escala reducida. Los elementos como los extremos de la red pueden diferir entre sus entornos, pero la parametrización de este tipo de datos variables puede ayudar a garantizar que el código sea coherente y que las diferencias de entorno estén bien definidas.

      Haga el trabajo de compilación solo una vez y transmita el resultado a través del proceso

      Un objetivo principal de un proceso de CI/CD es crear confianza en sus cambios y minimizar la posibilidad de un impacto inesperado. Analizamos la importancia de mantener la paridad entre los ambientes, pero un componente de esto es suficientemente importante como para ameritar atención adicional. Si su software requiere un paso de construcción, empaquetado o agrupación, ese paso se debe ejecutar solo una vez y el resultado obtenido se debe reutilizar a lo largo de todo el proceso.

      Esta guía permite prevenir problemas que surgen cuando el software se compila o empaqueta varias veces, lo cual permite que se inyecten ligeras inconsistencias en los artefactos obtenidos. Construir el software por separado en cada nueva etapa puede significar que las pruebas en entornos anteriores no se dirigían al mismo software que se implementará más tarde, lo que invalida los resultados.

      Para evitar este problema, los sistemas de CI deberían incluir un proceso de construcción como primer paso en el proceso que crea y empaqueta el software en un entorno limpio. El artefacto obtenido debería someterse a un control de versiones y cargarse en un sistema de almacenamiento de artefactos para retirarse en etapas posteriores del proceso, lo cual garantizará que la construcción no cambie a medida que avance en el sistema.

      Realice sus pruebas más rápidas con antelación

      Si bien sostener la velocidad del proceso es un gran objetivo general, algunas partes del conjunto de pruebas serán inevitablemente más rápidas que otras. Debido a que el sistema de CI/CD sirve como un conducto para todos los cambios que ingresan a su sistema, descubrir las fallas lo más pronto posible es importante para minimizar los recursos dedicados a las versiones problemáticas. Para lograr esto, priorice y ejecute sus pruebas más rápidas primero. Guarde las pruebas complejas y de larga duración para después de que validar la construcción con pruebas más pequeñas y de ejecución rápida.

      Esta estrategia tiene una serie de beneficios que pueden servir para que en su proceso de IC/CD no haya problemas. Lo alienta a comprender el impacto en el rendimiento de las pruebas individuales, le permite completar la mayoría de sus pruebas de forma anticipada y aumenta la probabilidad de fallas rápidas, lo cual significa que los cambios problemáticos pueden revertirse o arreglarse antes de bloquear el trabajo de otros miembros.

      Priorizar pruebas normalmente implica ejecutar primero las pruebas unitarias de su proyecto, ya que estas tienden a ser rápidas, aisladas y centradas en los componentes. Después, las pruebas de integración representan normalmente el siguiente nivel de complejidad y velocidad; a estas les siguen pruebas a nivel de todo el sistema y, finalmente, las pruebas de aceptación, que a menudo requieren algún nivel de interacción humana.

      Minimice las ramificaciones en su sistema de control de versiones

      Uno de los principios fundamentales de CI/CD es integrar los cambios en el repositorio primario compartido de forma temprana y frecuente. Esto ayuda a evitar costosos problemas de integración en el futuro cuando varios desarrolladores intentan fusionar cambios grandes, divergentes y conflictivos en la rama principal del repositorio en preparación para su lanzamiento. Normalmente, los sistemas de CI/CD se configuran para monitorear y probar los cambios enviados a solo una o a unas pocas ramas.

      Para aprovechar los beneficios que proporciona la CI, es mejor limitar el número y el alcance de las ramas en su repositorio. La mayoría de las implementaciones sugieren que los desarrolladores realicen la implementación directamente en la rama principal o fusionen los cambios de sus ramas locales al menos una vez al día.

      Básicamente, las ramas de las cuales su sistema de CI/CD no realiza un seguimiento contienen código no probado que debería considerarse como una responsabilidad para el éxito y el impulso de su proyecto. Minimizar las ramificaciones para fomentar la integración temprana del código de diferentes desarrolladores permite aprovechar las fortalezas del sistema y evita que los desarrolladores nieguen las ventajas que proporciona.

      Realice pruebas localmente antes realizar la implementación en el proceso de CI/CD

      En relación con el punto anterior sobre la detección temprana de fallas, se debería animar a los desarrolladores a que ejecuten localmente todas las pruebas posibles antes de la implementación en el repositorio compartido. Esto permite detectar ciertos cambios problemáticos antes de que bloqueen a otros miembros del equipo. Si bien el entorno de desarrollo local probablemente no pueda ejecutar el conjunto de pruebas completo en un entorno de producción, este paso adicional da a los individuos más confianza en que los cambios que realizan superan las pruebas básicas y vale la pena intentar integrarlos con la base de código más grande.

      Para garantizar de que los desarrolladores puedan realizar las pruebas de forma efectiva por sí mismos, su paquete de pruebas debería poder ejecutarse con un único comando que se pueda ejecutar desde cualquier entorno. El sistema CI/CD debería usar el mismo comando que emplean los desarrolladores en sus máquinas locales para iniciar pruebas en código fusionado con el repositorio. A menudo, esto se coordina proporcionando una secuencia de comandos de shell o makefile para automatizar la ejecución de las herramientas de pruebas de una manera repetible y predecible.

      Ejecute pruebas en entornos efímeros cuando sea posible

      Para garantizar que sus pruebas se ejecuten de la misma manera en varias etapas, a menudo se recomienda utilizar entornos de prueba limpios y efímeros cuando sea posible. Normalmente, esto significa ejecutar las pruebas en contenedores para abstraer las diferencias entre los sistemas host y proporcionar una API estándar para acoplar los componentes a varias escalas. Debido a que los contenedores se ejecutan con un estado mínimo, los efectos secundarios residuales de las pruebas no se heredan en las ejecuciones siguientes del conjunto de pruebas, lo que podría contaminar los resultados.

      Otro beneficio de los entornos de pruebas en contenedores es la portabilidad de su infraestructura de pruebas. Con los contenedores, los desarrolladores tienen más facilidad para replicar la configuración que se utilizará más adelante en el proceso sin necesidad de configurar y mantener manualmente la infraestructura, ni de sacrificar la fidelidad de entorno. Dado que los contenedores pueden girarse fácilmente cuando es necesario y luego destruirse, los usuarios pueden hacer menos sacrificios en términos de la precisión de su entorno de pruebas cuando se ejecutan pruebas locales. En general, el uso de contenedores se bloquea en algunos aspectos del entorno de ejecución para ayudar a minimizar las diferencias entre las etapas del proceso.

      Conclusión

      Si bien cada implementación de CI/CD será diferente, aplicar algunos de estos principios básicos le permitirá evitar algunos errores comunes y fortalecer sus prácticas de prueba y desarrollo. Como en la mayoría de los aspectos de la integración continua, una combinación de procesos, herramientas y hábitos permitirá que los cambios vinculados al desarrollo tengan más éxito e impacto.

      Para obtener más información sobre las prácticas generales de CI/CD y la configuración de varios servicios de CI/CD, consulte otros artículos con la etiqueta CI/CD.



      Source link