NEW
Font size
WorksheetsDevOps Compilacion y pruebas automatizadas en Github
Total questions: 56
Worksheet time: 28mins
¿Qué es un repositorio en GitHub?
Es como una carpeta de proyecto en la nube donde se almacenan archivos clave como código fuente, documentación y configuraciones.
Es una herramienta para crear presentaciones en línea.
Es un tipo de red social para compartir fotos.
Es un programa para editar videos.
¿Cuáles son los archivos clave que se pueden encontrar en un repositorio de GitHub?
Imágenes y videos
Código fuente, documentación, configuraciones
Música y audio
Juegos y aplicaciones
¿Qué función cumple la rama 'main' (o 'master') en un repositorio de GitHub?
A) Rama principal y estable, donde normalmente está el código listo para producción
B) Rama para pruebas e integración de nuevas funciones
C) Rama temporal creada por colaboradores
D) Rama para almacenar imágenes
¿Para qué se utiliza la rama 'dev' (u otras ramas de integración) en GitHub?
Para pruebas e integración de nuevas funciones
Para almacenar documentación
Para publicar el código final
Para crear ramas temporales
¿Qué son las 'feature branches' en GitHub?
Ramas temporales creadas por cada colaborador para desarrollar nuevas funciones o resolver errores
Ramas principales y estables
Ramas para pruebas
Ramas para almacenar configuraciones
Completa el espacio en blanco: En GitHub, los ______ son “fotografías” del estado de los archivos en un momento dado. Incluyen mensaje descriptivo de cambios.
Commits
Branches
Forks
Pull Requests
En GitHub, los ______ son solicitudes para integrar cambios de una rama a otra. Incluyen revisión de código y discusión entre colaboradores.
Pull Requests (PRs)
Commits
Forks
Issues
En GitHub, los ______ son un sistema para reportar errores, proponer mejoras o registrar tareas.
Issues
Commits
Branches
Pull Requests
Completa el espacio en blanco: En GitHub, las ______ son flujos de trabajo automatizados (CI/CD, despliegues, pruebas).
Actions
Branches
Commits
Repositories
¿Qué permite el historial de versiones mediante commits y ramas?
Permite regresar a cualquier estado del proyecto.
Permite eliminar archivos automáticamente.
Permite aumentar la velocidad de la computadora.
Permite crear gráficos de manera automática.
¿Cómo se evita conflictos directos entre usuarios en la colaboración de un proyecto?
Cada usuario trabaja en su propia rama.
Todos editan el mismo archivo al mismo tiempo.
Se ignoran los cambios de los demás usuarios.
Se elimina el control de versiones.
¿Qué archivo contiene la explicación general del proyecto?
LICENSE
README.md
CONTRIBUTING.md
¿Qué archivo sirve como guía para nuevos colaboradores?
README.md
LICENSE
CONTRIBUTING.md
¿Cuál es la funcionalidad de 'Clonar y descargar' en GitHub?
Obtener una copia local del repositorio
Registrar cambios localmente
Solicitar revisión de cambios
Combinar ramas
¿Para qué sirve 'Commits y push' en GitHub?
Crear ramas
Registrar cambios localmente y subirlos al repositorio remoto
Combinar ramas
Descargar el repositorio
Completa la frase: 'Branches' permite ______ para experimentar sin afectar la principal.
crear ramas
eliminar archivos
fusionar commits
cambiar contraseñas
¿Qué funcionalidad de GitHub se utiliza para solicitar revisión e integración de cambios?
Pull Requests
Forks
Issues
Commits
¿Cuál es el propósito de 'Merge' en GitHub?
Descargar el repositorio
Registrar cambios localmente
Combinar ramas
Crear ramas
¿Qué funcionalidad de GitHub permite hacer una copia independiente del repositorio para proponer cambios desde otro entorno?
Forks
Commits
Branches
Issues
¿Qué funcionalidad de GitHub se utiliza para reportar problemas, sugerir mejoras y debatir ideas?
Issues y discusiones
Pull requests
Forks
GitHub Pages
¿Qué funcionalidad de GitHub permite configurar reglas para no permitir subir directamente a main sin revisión?
Protección de ramas
Forking de repositorios
GitHub Actions
Issues
¿Qué funcionalidad de GitHub permite automatizar pruebas, construcción del código y despliegue?
Acciones de GitHub (CI/CD)
Repositorios de GitHub
GitHub Pages
GitHub Gist
Completa la frase: La rama 'dev' (development) es donde se ______ las nuevas funcionalidades antes de ser liberadas. Aquí se realizan pruebas de integración.
fusionan
eliminan
ignoran
ocultan
¿Para qué se crean las ramas 'feature/xxxx' en el flujo de trabajo con branches?
Para fusionar nuevas funcionalidades
Para desarrollar una nueva funcionalidad específica o corregir un bug
Para contener el código listo para producción
Para realizar pruebas de integración
¿Cuál es el primer paso en el flujo típico de trabajo?
Implementar los cambios en esa rama.
Crear una rama feature/nueva-funcionalidad desde dev.
Revisar y aprobar el PR.
Hacer un Pull Request (PR) hacia dev.
¿Qué significa PR en el contexto del flujo típico de trabajo?
Pull Request
Public Release
Private Repository
Project Review
¿Qué se debe hacer después de crear un Pull Request (PR) hacia dev según el flujo típico de trabajo?
Fusionar dev en main
Revisar y aprobar el PR
Implementar los cambios en esa rama
Crear una rama feature/nueva-funcionalidad
Completa el último paso del flujo típico de trabajo: 5. Fusionar dev en main cuando esté listo para __________.
producción
desarrollo
pruebas
diseño
Es importante conocer cómo se realiza el proceso Pull Request en GitHub para el pipeline CI/CD porque:
Permite integrar y validar cambios de forma controlada antes de automatizar el despliegue.
Evita la necesidad de pruebas en el código.
El Pull Request solo afecta a los repositorios privados.
No tiene impacto en el proceso de automatización.
¿Cuál de los siguientes es un beneficio de los Pull Request (PR)?
Permite discusión entre desarrolladores.
Dificulta la revisión de código.
Elimina pruebas antes de fusionar.
No tiene beneficios.
¿Cuál de los siguientes es un beneficio de los Pull Request (PR)?
Facilita la revisión de código (code review).
Impide la revisión de código.
Automatiza la eliminación de ramas.
No automatiza nada.
¿Qué beneficio proporciona un Pull Request (PR) antes de fusionar? Automatiza ______ antes de fusionar.
pruebas
documentación
comentarios
nombres de ramas
¿Cuál es el primer paso en el proceso de revisión de código?
A) Aprobar la rama
B) Crear un PR desde la rama feature/... hacia dev o main.
C) Solicitar cambios
D) Fusionar la rama
¿Qué deben examinar los revisores en el código?
Calidad y legibilidad, cumplimiento de estándares, ausencia de errores evidentes.
Solo la longitud de las líneas de código.
Únicamente los comentarios en el código.
El color del texto en el editor.
¿Qué sucede una vez aprobado el PR?
Se elimina la rama
Se fusiona la rama
Se rechaza el PR
Se solicita revisión adicional
Completa: Los revisores pueden aprobar, solicitar cambios o ____ el PR.
rechazar
duplicar
fusionar
ignorar
¿Qué significa prohibir push directo a main según la protección de ramas en GitHub?
Se puede actualizar main en cualquier momento
Solo se puede actualizar main mediante PR aprobados
Cualquier usuario puede modificar main
No se puede actualizar main nunca
Completa: Para requerir revisiones de código, mínimo ______ debe aprobar antes de fusionar.
un revisor
dos revisores
el autor
el gerente
¿Qué condición debe cumplirse para que un PR se fusione con validación CI/CD obligatoria?
El PR se fusiona automáticamente
El PR no se puede fusionar hasta que las pruebas automáticas pasen correctamente
No se requiere ninguna validación
Solo el autor puede fusionar el PR
¿Quiénes pueden aprobar cambios si se restringe quién puede aprobar?
Todos los usuarios
Solo usuarios con permisos específicos
Cualquier visitante
Solo el administrador del repositorio
¿Cuál es el primer paso para configurar la protección de ramas en un repositorio?
Selecciona "Ramas"
Ve a la configuración del repositorio
Agrega una nueva regla
Define el patrón de rama
¿Qué debes escribir para definir el patrón de rama que deseas proteger?
El nombre o patrón de la rama (por ejemplo, main o develop/*)
El nombre del repositorio
El nombre del usuario
El tipo de protección
¿Cuál es el propósito de habilitar 'Solicitudes de cambios requeridas' en la protección de ramas?
Permitir la fusión sin revisión
Obligar a que se solicite y apruebe una revisión antes de la fusión
Eliminar la necesidad de aprobaciones
Permitir cambios automáticos
¿Qué asegura la opción 'Verificaciones de estado requeridas' en la protección de ramas?
Que se fusionen ramas sin pruebas
Que ciertas pruebas automatizadas (como CI/CD) se completen con éxito antes de poder fusionar la rama
Que se eliminen las pruebas
Que se aprueben cambios automáticamente
Completa la frase: 'Exigir la resolución de la conversación' requiere que todas las discusiones en el PR sean ______ antes de la fusión.
resueltas
ignoradas
abiertas
pospuestas
¿Qué es la automatización de compilación?
Es el proceso de ejecutar automáticamente la compilación del código fuente (transformar código en ejecutables, empaquetar archivos o generar artefactos) cada vez que ocurre un evento en el repositorio, como un push o pull request.
Es el proceso de escribir manualmente el código fuente para cada nueva funcionalidad.
Es el proceso de revisar el código fuente en busca de errores de sintaxis de forma manual.
Es el proceso de documentar cada línea de código antes de ejecutar la compilación.
Completa la frase: Una ventaja de usar CI/CD es que ________ tiempo y reduce errores humanos.
Ahorra
Pierde
Duplica
Ignora
¿Qué permite detectar la integración continua/entrega continua (CI/CD)?
Errores tempranos (early feedback)
Más errores humanos
Menos eficiencia
Ningún error
¿Qué herramienta se usa en GitHub para crear workflows?
GitHub Actions.
GitHub Pages.
GitHub Wiki.
GitHub Issues.
¿Qué es GitHub Actions?
Un sistema integrado que permite crear workflows (flujos de trabajo) en archivos YAML ubicados en .github/workflows/.
Un editor de texto para programadores.
Una base de datos relacional de código abierto.
Un sistema operativo basado en Linux.
¿Cuáles son los componentes de un workflow en GitHub Actions?
A) Eventos, Jobs, Steps
B) Issues, Pull Requests, Commits
C) Branches, Forks, Merges
D) Repositorios, Usuarios, Organizaciones
¿Qué activa un workflow en GitHub Actions?
Eventos.
Pull Requests manuales.
Cambios en la configuración de GitHub.
Actualizaciones automáticas del sistema.
¿Cuál es la diferencia principal entre el enfoque tradicional y el enfoque DevOps para las pruebas unitarias?
Tradicional: Se ejecutan manualmente por desarrolladores antes de entregar el módulo a QA. DevOps: Automatizadas y ejecutadas en cada commit mediante integración continua (JUnit, PyTest, Mocha).
Tradicional: Se realizan al final del desarrollo. DevOps: Se integran progresivamente.
Tradicional: Manuales, centradas en la interfaz de usuario. DevOps: Automatizadas con Selenium.
Tradicional: Largas y manuales después de cada versión. DevOps: Automatizadas para ejecutarse con cada cambio del código.
¿Cómo se realizan las pruebas de integración en el enfoque tradicional y en el enfoque DevOps?
Tradicional: Se ejecutan manualmente por desarrolladores. DevOps: Automatizadas y ejecutadas en cada commit.
Tradicional: Se realizan al final del desarrollo, cuando los módulos ya están completos. DevOps: Se integran progresivamente y se prueban de manera continua en entornos de CI.
Tradicional: Manuales, centradas en la interfaz de usuario. DevOps: Automatizadas con Selenium.
Tradicional: Largas y manuales después de cada versión. DevOps: Automatizadas para ejecutarse con cada cambio del código.
¿Cuál es la diferencia entre el enfoque tradicional y el enfoque DevOps para las pruebas funcionales?
Tradicional: Se ejecutan manualmente por desarrolladores. DevOps: Automatizadas y ejecutadas en cada commit.
Tradicional: Se realizan al final del desarrollo. DevOps: Se integran progresivamente.
Tradicional: Manuales, centradas en la interfaz de usuario. DevOps: Automatizadas con Selenium, Cypress o Playwright; ejecutadas en pipelines.
Tradicional: Largas y manuales después de cada versión. DevOps: Automatizadas para ejecutarse con cada cambio del código.
¿Cómo se diferencian las pruebas de regresión en el enfoque tradicional y en el enfoque DevOps?
Tradicional: Se ejecutan manualmente por desarrolladores. DevOps: Automatizadas y ejecutadas en cada commit.
Tradicional: Se realizan al final del desarrollo. DevOps: Se integran progresivamente.
Tradicional: Manuales, centradas en la interfaz de usuario. DevOps: Automatizadas con Selenium.
Tradicional: Largas y manuales, después de cada versión. DevOps: Automatizadas para ejecutarse con cada cambio del código.
