valid - typeparam c#
¿Cómo permitir la implementación de múltiples tipos? (4)
Cuando hablamos sobre el significado de la vida, aquí están los dos centavos por un especialista en implementación (instalación): -): la respuesta es (parece :-) larga, pero contendrá información específica donde buscar cada punto. .
En primer lugar, establezcamos que la implementación NO es un obstáculo, aunque a muchos desarrolladores les gustaría verlo así (y como especialista en implementación, observo con bastante frecuencia que las partes interesadas en el proceso de desarrollo de software realmente piensan así: la implementación es sencilla Un poco olvidado hasta el día antes del envío :-)
Compáralo con coca para un ejemplo audaz y simple. Los "desarrolladores" producen el líquido, pero aquí es bastante fácil darse cuenta de que el trabajo aún no está hecho. :-)
Visual Studio en sí no es realmente compatible con las estrategias de implementación. Basado en varias áreas de implementación, como se menciona en la siguiente lista, hay, por supuesto, muchas tecnologías, algunas de ellas de Microsoft, que ayudan con eso. Lo que haría sería crear paquetes de configuración para diferentes clientes o escenarios que instalen subconjuntos de servicios como escenarios cliente / servidor u otros (consulte el número 3. en la siguiente lista).
En segundo lugar, como puede haber visto en otras respuestas, la implementación no es una implementación. En parte, esto depende si uno ve que la implementación simplemente produce archivos binarios de MSBuild o si se implementa en un sistema de prueba o si se implementa en el cliente, por ejemplo, actualizando el sitio web productivo o produciendo DVD o cargando archivos ejecutables en el sitio web de actualización ...
Hay varias áreas diferentes que seguramente tienen relaciones, pero cada área numerada es lo suficientemente grande y complicada como para tener especialistas propios:
La implementación vista como parte de la arquitectura tiene que lidiar con las estructuras y las entidades de origen y binario, por ejemplo, el proyecto y la estructura binaria (cuánto .exe, archivos .dll, cómo son sus dependencias, planificación de variaciones. => Como mencionó, usted está aquí en el área de (Visual Studio, etc.) soluciones, proyectos, así como espacios de nombres, especialmente en el área de WCF que tiene contratos, etc., tiene interfaces (POC #), etc. Tiene Nuget u otras herramientas para resolver y administrar dependencias. .NET tiene que ofrecer el concepto de ensamblaje para tratar esto, la arquitectura, por ejemplo, si implementar interfaces y contratos en ensamblajes propios, cómo lidiar con los escenarios de cliente / servidor, cómo los ensamblados dependen unos de otros, está arriba A ti y a la arquitectura.
- En cuanto a los servicios, hay una subtarea interesante sobre cómo alojar los servicios. Se pueden alojar en un servidor web, se pueden alojar en un archivo .exe, se pueden alojar en IIS u OWIN, etc. Enlaces para obtener más información:
Selfhosting en WCF: https://msdn.microsoft.com/en-us/library/ee939340.aspx
Selfhosting en un servicio de Windows, aquí con SignalR: https://code.msdn.microsoft.com/windowsapps/SignalR-self-hosted-in-6ff7e6c3
Alojamiento con OWIN: https://en.wikipedia.org/wiki/Open_Web_Interface_for_.NET
Implementación como parte de una integración local de Windows u otro sistema operativo: debe pensar en qué directorios del sistema tiene que colocar ciertos archivos o datos en general. Debe pensar en dlls compartidos, datos compartidos, datos de proyectos, datos temporales, datos específicos del usuario, registro, sistema de archivos, requisitos del logotipo de Windows, mejores prácticas, configuración del servicio, etc.
La implementación es un proceso de creación de configuraciones , instalaciones propias que, además de otras cosas, realizan las acciones necesarias mencionadas en 2 - con tareas adicionales como el front-end de instalación gráfica (GUI de configuración), el reconocimiento de licencias, la sección de novedades, la selección de componentes opcionales (solo piense en la configuración de Visual Studio), desinstale / repare / modifique las posibilidades, y así sucesivamente.
La implementación como un proceso devops , por ejemplo, parte de la integración continua, la entrega continua y / o la implementación continua . Aquí hay dos puntos principales: Técnicamente, para tener un proceso definido que está haciendo las cosas mencionadas en 2. y 3. (o alternativamente los pasos de implementación web) automáticamente como parte del proceso de compilación ("paso posterior a la compilación").
Esto puede incluir la creación de configuraciones o jerarquías de configuraciones, o trabajar sin configuraciones en absoluto). El segundo es permitir que los probadores, desarrolladores y administradores (o incluso clientes) vean al menos cada mañana o incluso más a menudo el ejemplo ya instalado de la última compilación nocturna o diaria, tal vez con varias variantes de implementación (cliente / servidor, básico / prof?) o en diferentes sistemas. Estás aquí medio en el mundo del desarrollador, medio en el mundo del administrador. Aquí, el punto principal a menudo no es crear configuraciones complicadas como en 3. sino principalmente para definir procesos propios de "empaquetar" y copiar (y firmar ... etc.), y para automatizarlos como parte del desarrollo (y prueba y entrega) proceso. Títeres y Chef ya fueron mencionados.Implementación como implementación web o en la nube (también puede ser el punto final de un proceso de devops): otros han dicho algo al respecto, omitiré los detalles aquí, pero una diferencia importante es que, si está hablando de implementación para el cliente o implementación en una Sistema intermediario de prueba o puesta en escena. Tal vez una cosa que haga que valga la pena mencionar este punto además de los devops, es que una implementación en servidores en línea, granjas de servidores o una nube tiene sus propios desafíos.
La implementación se considera principalmente como un proceso administrativo de distribución de software envasado, comprado y / o programado a todos los miles de PC de una empresa y sus empresas filiales. Por supuesto, existen herramientas especiales para esto, que incluyen estrategia de actualización, monitoreo, administración de licencias y más. Estás aquí en el mundo de la administración, ya no en el mundo de los desarrolladores. Los microservicios serán un desafío nuevo y alto para los administradores, que se utilizan principalmente para instalar y distribuir paquetes "grandes" como MS Office u Oracle o cualquier otro.
- Este tema no es tan aburrido para los desarrolladores como parece. Primaria porque los dos "mundos" de desarrolladores y administradores se están fusionando. Y los desarrolladores deben preocuparse por la opinión del cliente de "ejecutar el software en el mundo real". Devops es solo el comienzo. Todo el mundo conoce las máquinas virtuales, pero ahora tenemos redes definidas por software, aplicaciones virtuales, granjas de servidores virtuales, la nube, etc. Puede definir una arquitectura de implementación por dependencias sin ningún tipo de programación solo por configuración. Por lo tanto, la implementación debe ser parte de la arquitectura de su aplicación, pero en su mayoría no lo es (suficiente). De hecho, hasta ahora la vista de administrador está prácticamente integrada en ningún lugar con la vista de los productores / desarrolladores de software. En lo que respecta a Microsoft, el equipo de Windows hace mucho trabajo, especialmente. en la línea de productos del servidor, y eso nunca fue realmente coordinado estratégicamente con el equipo de desarrolladores AFAIK (esto probablemente sea válido para TODAS las tiendas de software hasta ahora :-)
Actualmente, muchas personas que publican relacionadas con devops o las palabras de moda continuas no tienen mucha experiencia con las configuraciones. Las configuraciones de construcción pueden verse como una tecnología especial entre los otros pasos necesarios.
Dado que está interesado en saber más acerca de 3. (configuraciones): si no desea solo copiar archivos ejecutables, sino tener la funcionalidad de configuraciones completas, que hacen más trabajo que solo copiar, parte de la estrategia de configuración puede ser: tienen configuraciones de paquetes (a veces llamadas configuraciones de suite o configuraciones de arranque) con características de selección propias. Pueden llamar a las pequeñas configuraciones subyacentes, por ejemplo, para sus microservicios.
Visual Studio en sí ya no tiene un soporte propio para los tipos de configuración más sofisticados como MSI, y especialmente nunca ha tenido para agrupar configuraciones en paquetes , lo que puede ser una solución posible para implementar un grupo (o variantes de grupos) de servicios: VS tiene, por ejemplo, algo de soporte para la implementación de "ClickOnce", pero esto se ha hecho más para clientes de base de datos ("inteligentes") que para servicios o incluso microservicios. ClickOnce: https://msdn.microsoft.com/de-de/library/31kztyey.aspx
Un reemplazo para la falta de creación de configuración "real" en Visual Studio puede ser el conjunto de herramientas de WiX, que es un proyecto de código abierto formado por empleados de Microsoft. O InstallShield Express (que es una variante gratuita, pero limitada de las comerciales). Con ambos puede crear configuraciones de MSI completas, que son quizás el tipo de configuración más sofisticado en el zoológico de configuración de Windows .
a) Por supuesto, hay otros tipos de configuraciones además de MSI (también conocido como Windows Installer), son de proveedores externos que son más o menos propietarios pero más simples: por ejemplo, Nullsoft - NSIS e InnoSetup .
No daré enlaces para crear configuraciones de MSI individuales porque se pueden encontrar fácilmente con los enlaces de creación de paquetes de configuraciones de MSI en las siguientes líneas:
b) La herramienta para crear configuraciones que seleccionan e instalan otras (subconjuntos definidos de subyacentes) en el "mundo" de Wix se llama "Grabar":
Creando paquetes de configuraciones con Burn : http://wixtoolset.org/documentation/manual/v3/bundle/
Soporte especial (pagado) para esto que puede obtener, por ejemplo, del fundador de WiX que creó una compañía especialmente para esto: https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/ Rob Mensching, El fundador, se puede encontrar aquí en SA, así como responder a preguntas dedicadas.
c) Configuraciones de InstallShield Suite: otra es la herramienta InstallShield ya mencionada, pero para ello necesitará su variante InstallShield Premium , que cuesta dinero:
http://helpnet.installshield.com/installshield21helplib/helplibrary/SteCreatingSuites.htm
d) Setup-Factory : https://www.indigorose.com/setup-factory/
e) Estoy seguro, muchas personas recomendarían echar un vistazo a Docker . Las aplicaciones virtuales no son solo configuraciones, sino que se aíslan en el estado "instalado" de otras aplicaciones como un sandbox. Ver, por ejemplo, https://docs.docker.com/docker-for-windows/
f) La lista no estaría completa si no mencionara a APP-V como tecnología de instalación de aplicaciones virtuales que comparte algunas características pero no todas con la ventana acoplable. Pero estas tecnologías no están realmente hechas para organizar múltiples entregas, sino para entregar una sola aplicación. Y Microsoft ha definido un nuevo tipo de configuración llamada AppX. Especialmente tiene que diferir, si desea crear aplicaciones de escritorio "antiguas" (completas) para Windows, donde las configuraciones de MSI son la tecnología conocida o almacenar aplicaciones que son el nuevo tipo desde Windows 8 (también conocidas como aplicaciones universales de Windows). aplicaciones modernas también conocidas como aplicaciones de Metro).
AppX : https://msdn.microsoft.com/en-us/library/windows/desktop/hh446767(v=vs.85).aspx AppX apunta a un tipo de configuración más simple que MSI.
Aplicaciones universales de Windows (UWP) : https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp
Para algo más detallado tenemos que saber más de sus requerimientos.
En mi búsqueda del significado de la vida , me topé con una publicación de blog que mencionó que su estrategia de implementación no es su arquitectura , es simplemente un detalle de implementación , y como tal debemos diseñar para permitir diferentes patrones de implementación, ya sea que desee despliegue su sistema en 1 nodo o multinodo, u otro tipo de estructura.
¿Las últimas versiones de Visual Studio proporcionan algún tipo de flexibilidad (además de azul) para poder implementar servicios en una variedad de estrategias?
Por ejemplo, digamos que tengo una solución.
Acme Solution
--Acme Startup Proj
--Acme Service A.csproj
--Acme Service B.csproj
--Acme Service C.csproj
Quiero poder implementar esta solución completa como 1 solución, o me gustaría poder implementar 3 binarios separados, uno para cada servicio micro .
AcmeServiceA.exe
AcmeServiceb.exe
AcmeServicec.exe
¿Qué le ofrece Visual Studio en términos de flexibilidad de configuración de implementación?
Las técnicas de implementación variarán según las tecnologías en las que se construye tu aplicación. A modo de ejemplo, voy a suponer que estamos tratando con servicios o sitios web.
Ha especificado dos escenarios de implementación: implementación de un solo proyecto (por ejemplo, microservicio), e implementación de todos los proyectos (implementación completa). Vamos a empezar poco a poco ...
Despliegue de un proyecto individual
Lo principal a planear es que cada átomo desplegable (esto podría ser un proyecto o un servicio + backend DB ... algo tan pequeño como usted preferiría no dividirlo en implementaciones más pequeñas).
Para los proyectos web (ya sea proyectos de API web u otros tipos), las opciones integradas de Visual Studio se pueden resumir generalmente en: WebDeploy , Azure y ahora con .NET Core, Docker images . No voy a entrar en los detalles de cada uno, porque esas son preguntas separadas. Pero puedo referirme a algunos detalles para que investigue si suenan interesantes (estoy más familiarizado conceptualmente con WebDeploy, así que me referiré mucho a eso, pero no estoy a favor o en contra).
Si estuviera usando WebDeploy, por ejemplo, podría hacer que cada proyecto produzca un paquete WebDeploy. (Una vez más, busque esto para obtener más detalles sobre cómo hacerlo). Este paquete se puede diseñar para que contenga una carga útil de archivo (los archivos de sitio / servicio) así como una carga útil de base de datos u otros subátomos usando el modelo de proveedor de WebDeploy. Visual Studio tiene un soporte bastante decente para este escenario, y hay documentación al respecto.
O podrías generar una imagen Docker. Desde mi entendimiento (y la falta de experiencia con Docker todavía), si desea implementar su servicio web y su base de datos, deberían estar en contenedores separados. Pronto te encontrarás construyendo estos por ti mismo fuera de VS. Eso no es algo malo, Docker suena muy flexible una vez que lo aprendes; Pero estas dejando el IDE para esto.
De cualquier manera, ahora puede implementar el paquete atómico. Esta fue la parte fácil.
Desplegando la solución
Entonces, tienes muchos de estos paquetes de despliegue atómico. ¿Cómo los desenrollas a todos?
Bueno, en este punto, VS no te proporciona mucho. Y es difícil justificar lo que VS debería hacer aquí. Casi todas las organizaciones van a tener reglas ligeramente diferentes. ¿Despliega desde su IC? ¿Crea paquetes y los implementa en diferentes entornos en su canal de lanzamiento? ¿O lo hace en la nube y en los entornos de intercambio dinámico (como las ranuras de implementación de Azure)?
Una solución nativa de VS tiene que ser extremadamente configurable (y por lo tanto extremadamente complicada), o será demasiado simple para satisfacer las necesidades de la mayoría de los clientes. (Dejando de lado, el soporte inicial para WebDeploy en VS2010 tuvo un error en el primero de estos. Era extremadamente configurable y muy difícil para el cliente o incluso para el equipo del producto encerrar sus cabezas en torno a todos los escenarios posibles. Fuente: el control de calidad para esa característica una vez.)
Realmente en este punto, debe determinar cómo y cuándo implementará sus implementaciones. Necesita algo para orquestar cada una de estas implementaciones.
VS generalmente organiza las cosas con MSBuild. Nuevamente, no estoy abogando por esto como su plataforma de orquestación (en realidad no me gusta por eso ... está bien para la configuración de su proyecto, pero IMO no es una buena opción para la administración de tareas), pero si esto es lo que quiere usar, puede funcionar En realidad, es bastante simple si lo estás utilizando para el escenario del Proyecto Web. Puedes construir tu solución y usar el parámetro /p:PublishOnBuild=true . Si está utilizando WebDeploy para publicar directamente, ¡listo! Si está creando Paquetes de Despliegue Web, entonces aún debe presionarlos, pero al menos los ha creado todos a la vez.
Si está utilizando Paquetes de Despliegue Web, cada uno generará un script para usar para la publicación. También hay formas de pasar diferentes parámetros de WebDeploy, por lo que puede reutilizar el mismo paquete (salida de compilación) para publicar en diferentes entornos. Sin embargo, tendrá que escribir su propio script para combinar todo esto en una implementación megalítica.
Lo mismo ocurre con Docker también. Puede obtener un conjunto de imágenes, pero aún necesita algo para orquestar la publicación de todas ellas. Herramientas como Kubernetes pueden ayudarlo a implementar, o en caso de problemas, revertir.
También hay más plataformas de orquestación genéricas como Octopus Deploy .
¡Qué insatisfactorio!
Sí, un poco apesta que no haya una solución lista para usar para implementaciones a gran escala. Pero si lo hubiera, no funcionaría para el 95% de los equipos. La mayoría de lo que proporciona VS es suficiente para que un equipo de desarrollo individual o muy pequeño pueda enviar su código a sus servidores. Cualquier equipo más grande, y obtendrá un mejor kilometraje al construir un sistema que se adapte a la forma en que opera su equipo. Hay muchas herramientas por ahí y ninguna de ellas funciona perfectamente en todos los casos. Encuentra uno que funcione para ti y estarás bien. Y al final, todo se reduce a empujar archivos y ejecutar scripts. Si no te gusta un sistema o herramienta, puedes probar otro.
Realmente depende del caso de uso exacto, cómo lograrlo, de la flexibilidad requerida y de su definición de un nivel aceptable de dicha flexibilidad.
Tomando su ejemplo con estos tres ejecutables diferentes como microservicios separados (Servicio A, B, C) y como un servicio completo (Inicio) en el contexto de Web.Api, podría hacer lo siguiente:
Cada proyecto (Servicio A, B, C) puede diseñarse como un ejecutable auto hospedado de OWIN separado (como se describe en Usar OWIN para auto-hospedar la API web de ASP.NET 2 ) y proporcionar uno o más puntos finales para ser expuestos.
El proyecto principal (Inicio) también podría ser un host propio de OWIN o una aplicación IIS Web.Api regular que haga referencia a los tres proyectos (Servicio A, B, C) y cargar sus respectivos puntos finales en su propia rutina de
Startup(y opcionalmente puntos finales adicionales de sí mismo).
Luego, puede usar un proyecto de configuración separado en Visual Studio (o un proyecto externo en un entorno completamente diferente) y hacer uso de tecnologías de implementación como Puppet, Chef, o lo que sea necesario para implementar según sus escenarios.
Su código no se verá afectado por la implementación que realmente desea realizar y esa configuración respectiva se administrará por separado.
Si esto no responde a su pregunta o si he entendido mal su pregunta, ¿podría aclararla y dar más detalles?
Si está buscando una experiencia de implementación mejorada en Visual Studio, consulte la solución en el paquete InstallShield Limited Edition de Flexera (ISLE, http://blogs.msdn.com/b/visualstudio/archive/2013/8/15/what-s-new-in-visual-studio-2013-and-installshield-limited-edition.aspx ). ISLE es una excelente solución para aquellos clientes que buscan capacidades adicionales que no se encuentran en los proyectos del instalador de Visual Studio, como la integración de TFS y MSBuild, el soporte para crear nuevos sitios web y el soporte de etiquetado ISO 19770-2, etc.
Con las plantillas de proyectos de Instalación y Despliegue, puede elegir empaquetar todos los ensamblajes en la solución o cada uno individualmente como MicroService mediante Proyectos de Instalación, Web, CAB o Módulo de combinación:
Luego elija qué ensamblajes están incluidos:
