Multiple environment deployment strategy and infrastructure
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- firebase, gcp
- Área
- ci-cd, cloud, devops, infrastructure
Línea de trabajo
Empieza revisando la configuración de deployment y la configuración existente del proyecto de Firebase/Google Cloud, y después compárala con los entornos propuestos local, dev, demo y prod. Define los puntos de entrada del deployment y el flujo de release antes de implementar nada; terminado significa que staging se despliega desde main y production se despliega mediante una elección intencionada.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Idea:
- a deploy to a staging environment (need to create this) should happen automatically when a push to
mainoccurs - a deploy to production environment should happen by intentional choice (usually after confirming things are all good in staging, but also perhaps after a hot-fix bug is remediated)
Pre-req: must build a new firebase/gcloud project environment.
@Justin-MacIntosh 's specific ideas based on his experience:
- local: working on a local branch
- dev: deployed from latest
main, the environment QA testing happens on (similar to staging above) - demo: deployed ad-hoc and untouched, used for showing people outside the team the product
- prod: deployed from latest GitHub release, the actual deployed product
- Lenguaje dominante
- Java
- Estrellas
- 16
- Forks
- 5
- Merge medio
- 17 h 24 min
- PR fusionados (30 d)
- 23
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de CodeForPhilly/benefit-decision-toolkit
-
Make docs website more visibleAbiertodocumentation Good for newcomer quick win
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CodeForPhilly/benefit-decision-toolkit#519 ·
Los mantenedores suelen responder en 1 día
-
documentation quick win
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CodeForPhilly/benefit-decision-toolkit#445 ·
Los mantenedores suelen responder en 1 día
-
Make issue templatesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
CodeForPhilly/benefit-decision-toolkit#425 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
CodeForPhilly/benefit-decision-toolkit#525 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
Los mantenedores suelen responder en 1 día
Todos los issues de CodeForPhilly/benefit-decision-toolkit
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
go 🏃 testing 🧪
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
valkey-io/valkey-glide#7239 ·
Los mantenedores suelen responder en 2 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
github/copilot-sdk#2793 ·
Los mantenedores suelen responder en 1 día