2009-07-11 11 views
6

Normalmente pruebo mi código localmente en mi máquina de trabajo y luego lo muevo al entorno de desarrollo y finalmente al entorno de producción. ¿Cuál es la mejor manera de usar el modo de depuración/liberación para este escenario? ¿Solo necesito preocuparme por el modo de depuración en mi máquina? ¿Debo publicar el modo de depuración o el modo de lanzamiento para el desarrollo? Sé que probablemente debería publicar usando el modo de lanzamiento para producción. Realmente no presté atención a todo esto antes, así que he estado trabajando solo en el modo de depuración todo el tiempo, y sé que no debería hacerlo.¿Cómo debo usar el modo de depuración/liberación en Visual Studio?

Editar: Gracias por las respuestas. Parece que es una buena idea usar solo el modo de depuración en mi propia máquina. Aunque está en una máquina de desarrollo, básicamente está lanzando al público (compañeros de trabajo, qa), por lo que debería estar en modo de lanzamiento. Y, por supuesto, debería ser el modo de liberación cuando se libera a prod.

Respuesta

12

Al liberar/publicar una aplicación, debe hacerlo en el modo de lanzamiento. El modo de lanzamiento es solo para eso, liberando aplicaciones. El código producido es generalmente más eficiente y muchos elimina muchos controles que están más asociados con la fase de desarrollo de una aplicación.

En un día normal, debe desarrollar en modo Depuración. La mayoría de los idiomas insertan controles adicionales en una aplicación de modo de depuración. Estos detectan más errores pero tienden a ralentizar la aplicación un poco.

Sin embargo, también debe hacer pruebas significativas del modo de lanzamiento como parte de su proceso de desarrollo. Los clientes solo verán la versión del modo de lanzamiento de su producto y es posible que los errores sean específicos del modo de depuración/liberación. Las comprobaciones de errores insertadas en el modo de depuración pueden presentar efectos secundarios que ocultan errores reales en su aplicación.

+0

@JaredPar "Las comprobaciones de errores insertadas en el modo de depuración pueden presentar efectos secundarios que ocultan errores reales en su aplicación". -- ¿Puedes elaborar? – TGnat

+3

@TGnat, hay casos obvios donde los controles alteran el estado global (mal, pero existen). El más sutil es que la simple ejecución de un cheque altera el tiempo de su aplicación. He visto muchos problemas de subprocesos donde las costosas comprobaciones del modo de depuración escondían problemas de temporización subyacentes haciendo que un subproceso dure más en el modo DEPURAR que en el modo LIBERACIÓN. Esto permitió que otros hilos alcanzaran un estado completo y parecieran una aplicación en funcionamiento. Una vez que se quitó el cheque en el modo RELEASE, el subproceso se ejecutó más rápido y expuso la condición de carrera. – JaredPar

3

En general, SIEMPRE despliegue las versiones de versión a producción. La depuración aumentará el peso de su conjunto y degradará el rendimiento.

Si está desarrollando aplicaciones ASP.NET, dejar el modo Depuración en realidad cambia cómo/cuándo sus páginas son compiladas por el compilador JIT y degrada significativamente el rendimiento para agregar una mejor capacidad de depuración interactiva. En cuanto a qué versión instalar en desarrollo ... si está ejecutando pruebas unitarias contra desarrollo, probablemente sea una buena idea implementar la compilación Debug para que pueda obtener la mayor información de depuración cuando fallan las pruebas o se producen excepciones . Sin embargo, existe la esperanza de contar con un entorno adicional de Pruebas o Preproducción en el que pueda ejecutar sus pruebas de integración y realizar pruebas manuales allí. Ese entorno de prueba/preproceso debería usar DEFINITIVAMENTE compilaciones de versión para que pueda ver los verdaderos problemas de rendimiento y compilación antes de pasar a la producción.

Si no tiene este nivel intermedio de Prueba/Preproceso, entonces le sugiero que ejecute su entorno Dev con Release. En otras palabras, debe ejecutar al menos un nivel antes de la producción en la configuración de Release.

Para obtener más información sobre lo que puede hacer con las configuraciones, tengo una publicación de blog específicamente para Silverlight (http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html). Hay un enlace al artículo más genérico de Scott Hanselman sobre configuraciones de compilación y diferentes entornos.

2

De forma predeterminada, la versión compilada se compilará con más conmutadores del optimizador, lo que dará como resultado un código más rápido y pequeño, que es lo que normalmente desea lanzar a los clientes (de ahí el nombre). T

La creación de depuración casi no realiza optimizaciones, lo que significa que cuando se utiliza el depurador, el código subyacente de la máquina se corresponde más con el código fuente, lo que ayuda a la depuración.Además, la compilación de depuración de forma predeterminada inserta verificaciones adicionales de código de tiempo de ejecución que detectarán errores comunes, como el acceso a miembros de matrices no inicializados.

Tenga en cuenta que puede compilar compilaciones de liberación con símbolos de depuración, simplemente se vuelve más difícil para el depurador asignar la instrucción actual en el código de máquina a la línea de origen adecuada.

6

que siguen este enfoque:

código
  • /ciclo de depuración en mi estación de trabajo: DEBUG
  • ejecutar pruebas unitarias en mi estación de trabajo: debug
  • perfilado en mi estación de trabajo: Liberación
  • durante la noche construir y Pruebas automatizadas: RELEASE (realiza una instalación desatendida)
  • pruebas prácticas por el equipo de control de calidad: RELEASE

Todas las pruebas se deben llevar a cabo al menos en la compilación de lanzamiento, porque es lo que se va a enviar. La creación de perfiles en la compilación de depuración generalmente no tiene sentido (especialmente en C++) porque los montones de depuración tienen una gran cantidad de comprobación adicional que cambia totalmente el perfil de rendimiento de una aplicación típica.

Cuestiones relacionadas