DEV Community: Victor Canseco Soto

Como publicar un proyecto de Base de datos de Visual Studio a Azure SQL con Azure Pipelines

Victor Canseco Soto — Sun, 21 Aug 2022 01:08:00 +0000

Hola nuevamente, el día de hoy les tengo un proyecto bastante interesante ya que a todos nos ha pasado que se vuelve un caos controlar los cambios que tenemos en nuestras bases de datos, por ejemplo con cada iteración de nuestro proyecto tenemos pequeños cambios a la base de datos, los cuales muy comúnmente los controlamos mediante scripts de SQL, la mayoría de las veces los colocamos dentro del mismo repositorio de nuestra aplicación y en cada deploy a productivo tenemos que ejecutar estos scripts dentro de la base de datos manualmente. Sin embargo, a todos los que hemos realizado esta mala practica nos ha pasado que se nos olvida ejecutar alguno de ellos o no se ejecutan en el orden correcto y cuando todo se integra algo se rompe.
Bueno para solucionar este problema dentro de Visual Studio podemos crear un proyecto de Base de datos, el cual podemos colocar dentro de un Repo para controlar las versiones y cambios a nuestra Base de datos y todos estos cambios los podemos realizar controlada y automáticamente hacia nuestra base de datos a través de Azure Pipelines. A continuación, te mostraré como realizar esto paso a paso.
Primero que nada, comenzamos creando nuestro proyecto de base de datos dentro de Visual Studio.

Seleccionamos el proyecto de SQL Server

Le ponemos un nombre y creamos el proyecto

Una vez creado el proyecto, la solucion se encuentra en blanco; para ligar nuestra base de datos tenemos varias opciones, una de ellas nos permite importar toda nuestra base (tablas, store procedures, triggers, logins y demás objetos de la db) lo cual es de gran ayuda si es que ya tenemos una base de datos creada. Para esto damos click derecho en el proyecto -> Import -> Database.

Seleccionamos nuestra base de datos

Le damos **Start **para iniciar la importación

Una vez terminada la importación podemos ver dentro del explorador de soluciones todos los objetos de nuestra DB.
En mi caso la base esta vacía, por lo cual creare 2 tablas (User y Product); esto con la finalidad de demostrar como se realizan los cambios a nuestra base de datos.

Antes de crear los pipelines debemos configurar nuestro proyecto para que se pueda realizar el despliegue hacia Azure SQL, para ello primero configuramos el servidor objetivo como Azure SQL; por alguna extraña razón, aunque importemos de Azure la base de datos Visual Studio mantiene la configuración como SQL Server 2016 lo cual al momento de hacer el despliegue a nuestra base en Azure nos marcará error ya que son incompatibles. Para corregir esto damos click derecho en nuestro proyecto y seleccionamos Propiedades.

Ahí cambiamos el Target Platform a Azure SQL

Una vez configurado nuestro Target Platform procedemos a crear el perfil de publicación, este perfil es necesario para realizar el deploy a nuestra base de datos. Para crearlo damos click derecho sobre el proyecto y seleccionamos Publish…

Presionamos el botón Create Profile, una vez que el botón se inhiba damos click en cerrar(cancelar).

Como podemos observar en nuestro proyecto se crea un archivo dentro de la raíz de este, en mi caso se generó el archivo DBproject.publish.xml

Procedemos a guardar nuestro proyecto dentro de un Repo de Azure, en esta parte podemos observar que el perfil de publicación no lo agrega al control de código, para corregir esto le damos click derecho y seleccionamos: Git -> Add Ignored File to Source Control…

Después de esto damos nuevamente click derecho sobre el perfil y seleccionamos Propiedades; este cambio lo debemos realizar ya que por default el archivo no queda con la opción de copiar al directorio destino.

Seleccionamos Copy Always en la propiedad de Copy to Output Directory.

Como siguiente paso creamos un nuevo pipeline dentro de Azure, para esto seleccionamos un nuevo pipeline de Azure.

A continuación, pongo el archivo YAML para que puedas modificar el código de acuerdo a la configuración de tu proyecto.

trigger:
- master

jobs:
- job: Job_1
  displayName: Build DB project.
  pool:
    vmImage: windows-2019

  steps:
  - checkout: self
    clean: true
  - task: VSBuild@1
    displayName: Build solution DBproject
    inputs:
      solution: DBproject/DBproject.sqlproj
      msbuildArgs: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=”$(Build.ArtifactStagingDirectory)\\”
      platform: any cpu
      configuration: release
  - task: CopyFiles@2
    displayName: Copy Dacpac to Build
    inputs:
      SourceFolder: DBproject/bin/Output
      Contents: DBproject.dacpac
      TargetFolder: $(Build.ArtifactStagingDirectory)
  - task: CopyFiles@2
    displayName: Copy Publish profile
    inputs:
      SourceFolder: DBproject
      Contents: DBproject.publish.xml
      TargetFolder: $(Build.ArtifactStagingDirectory)
  - task: PublishBuildArtifacts@1
    displayName: 'Publish Artifact'
    inputs:
      ArtifactName: DBproject

Guardamos y ejecutamos nuestro pipeline el cual debe ejecutarse correctamente; continuamos con la creación de nuestro Release para esto damos click al botón crear New release pipeline

Seleccionamos un pipeline vacío. Y en la sección de Artifacts **seleccionamos como **Source Type: Build.
Seleccionamos nuestro proyecto y el Source de nuestro proyecto y Default Version: _Latest _

En la sección de Stages, damos click en Jobs **y agregamos una nueva Tarea al Agent, esta será de tipo **Azure SQL Database deployment

Esta tarea la configuramos con los datos de nuestra base de datos e información de nuestro proyecto, deberá de quedar de la siguiente forma:

Ejecutamos nuestro pipeline y esperamos a que termine el deploy, una vez terminado podemos revisar nuestros cambios en la base de datos; en mi caso deben aparecer las dos tablas que agregue.

Para poder revisar que efectivamente se respeten los cambios a la base de datos sin afectar a lo existente; agregare registros a una de las tablas que cree.

Creamos una nueva tabla para este ejemplo creare la tabla Store.

Ejecutamos nuestros Pipelines y esperamos a que termine el deploy a nuestra base de datos. Revisamos que nuestros cambios estén aplicados y también podemos revisar que no se haya afectado la información que ya teníamos almacenada en nuestra base de datos.

Como podemos observar nuestra información esta intacta y solo se aplicaron los cambios, como en este caso crear una tabla nueva.

Espero que este tutorial de como crear un proyecto de base de datos y hacer el deploy hacia una base de datos en Azure te sea de ayuda. Con esto tenemos controlado y automatizado los cambios que realice el equipo de desarrollo a la base de datos.

Mi website

Desplegando una Web App de .Net Core con Docker y Azure Pipelines (I)

Victor Canseco Soto — Sat, 13 Aug 2022 01:14:00 +0000

Hace unos días empecé a probar Docker con proyectos desarrollados en .Net y desplegarlos en servicios de Azure, para lo cual me encontré con dos situaciones: la primera es la escasa documentación que existe o se encuentra desactualizada; y la segunda es que el proceso es relativamente sencillo.
Por lo cual decidí que lo mejor será compartir mi experiencia en este proceso; así que manos a la obra.
Primero creamos un proyecto de ASP.NET Core Web App:

Colocamos el nombre de nuestro proyecto:

Seleccionamos la opción de Enable Docker y seleccionamos el SO como Linux

Una vez que termino de crear el proyecto podemos notar que por default el target de la compilación se cambió a Docker **😱. Por el momento vamos a cambiar este target al nombre de nuestro proyecto; en mi caso **WebAppDocker.

Otro cambio que se puede observar es que a nuestro proyecto le agrego un archivo Dockerfile; el cual contiene la configuración para Docker el cual analizaremos más adelante. Por el momento revisamos que nuestro proyecto funcione correctamente sin utilizar Docker.

Una vez que nos cercioramos de que nuestra aplicación funciona correctamente continuemos con probar esta funcionalidad, pero ahora dentro de nuestro contenedor de Docker. Antes de continuar te preguntarás y si es un proyecto existente como hago para que se ejecute en un Docker Container; con Visual Studio es relativamente fácil para esto: Dar click derecho sobre el nombre del proyecto -> Add -> Docker Support

Seleccionamos el Target OS: Linux

Esto nos genera el archivo Dockerfile adecuado para nuestro proyecto.

Ahora si ejecutamos el proyecto con el Target: Docker

Como podemos observar dentro del Visual Studio tenemos una herramienta para visualizar los contenedores, en la cual tenemos la misma funcionalidad que se tiene dentro de Docker Desktop.

Al ejecutar nuestro proyecto en VS podemos observar que se crea la imagen y a su vez se ejecuta el contenedor, lo cual en otro escenario significaría que con esta imagen ya podemos levantar nuestro contenedor dentro de Azure; lamentablemente para mi sorpresa esto no es así ya que por alguna extraña razón al detener el proceso de debug en el VS ya no se ejecuta la aplicación correctamente 🤔🤔. Para entender la razón del porque la app corriendo en el contenedor ya no funciona, aunque el proceso esta corriendo en Docker y no marca ningún error; revise los pasos que realiza el Visual Studio para compilar, empaquetar y publicar el proyecto. Esta información la podemos revisar en la terminal de Salida del VS.

Al revisar el comando docker build solo recibe los parámetros del archivo Dockerfile a construir, --force-rm -t para borrar la imagen existente y labels, así que descartamos el problema en la construcción de la imagen de Docker.

docker build -f "C:\Users\vicos\CursoDocker\WebAppDocker\WebAppDocker\WebAppDocker\Dockerfile" --force-rm -t webappdocker  --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=WebAppDocker" "C:\Users\vicos\CursoDocker\WebAppDocker\WebAppDocker"

El siguiente paso es revisar hasta el final del log aparece el comando docker run.

docker run -dt -v "C:\Users\vicos\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\Users\vicos\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" -v "C:\Users\vicos\AppData\Roaming\ASP.NET\Https:/root/.aspnet/https:ro" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=https://+:443;http://+:80" -P --name WebAppDocker --entrypoint tail webappdocke1r -f /dev/null

En los parámetros que recibe este comando si observamos algunos parámetros adicionales, empezando con el parámetro -v "C:\Users\vicos\vsdbg\vs2017u5:/remote_debugger:rw" este parámetro monta un volumen hacia el debugger lo cual no es necesario para la ejecución en productivo de nuestra WebApp en Docker.
Los siguientes dos parámetros son utilizados por el Web Server para definir el certificado https que se va a utilizar, como podemos visualizar se referencian hacia una ruta local del equipo de desarrollo lo cual en un ambiente de producción no tendremos acceso a estas carpetas. Para agregar al contenedor el certificado hay que modificar nuestro proyecto.
Dentro del explorador de Windows nos ubicamos en la carpeta %USERPROFILE%\AppData\Roaming\ASP.NET\Https en la cual encontraremos el certificado para nuestro proyecto.

Este archivo lo copiamos y lo colocamos dentro de nuestro proyecto.

Damos click derecho -> propiedades (Alt + Enter)

En la propiedad de “Copy to Output Directory” seleccionamos la opción “Copy Always”

Abrimos el archivo Appsettings.json y agregamos lo siguiente

"Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "WebAppDocker.pfx",
        "Password": "f9503e4f-0cd7-4630-b752-4d41df791f69"
      }
    }
  }

Una ves realizado estos cambios continuamos al siguiente parámetro que no es necesario que se proporcione al comando docker run. -e "ASPNETCORE_LOGGING_CONSOLE_DISABLECOLORS=true" este parámetro es opcional ya que solo deshabilita los colores en la consola del log.
Los siguientes dos parámetros ENVIRONMENT y URLS **si son necesarios por lo cual los dejaremos dentro de nuestro script de ejecución, junto con el parámetro -P que nos permite publicar los puertos expuestos hacia puertos aleatorios; esto lo cambiaremos más adelante cuando publiquemos nuestra imagen de docker hacia un servicio de Azure.
Despues viene el nombre de nuestro container y en teoría debería ir el nombre de la imagen que deseamos ejecutar pero en el comando que ejecuta VS sobrecarga el entrypoint por un tail webappdocker:dev -f /dev/null**, lo cual no es necesario para nuestro ambiente en ejecución.
Con estos cambios nuestro comando docker run quedaría de la siguiente manera:

docker run -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=https://+:443;http://+:80" -P --name WebAppDocker webappdocker

Con esto comprobamos que efectivamente nuestra aplicación se encuentre levantada dentro del container.

Como podemos observar nuestra WebApp se encuentra ejecutándose correctamente dentro del container de docker y tenemos nuestra aplicación lista para ser desplegada dentro de nuestro servicio de Azure.

En la siguiente parte crearemos los Pipelines de Azure para su compilación y despliegue hacia el servicio de Azure.

Los espero para la próxima, ¡mis mejores deseos, salud y éxitos!

¿Qué es Bicep?

Victor Canseco Soto — Sat, 06 Aug 2022 04:20:36 +0000

Actualmente existen varias herramientas para Infrastructure as Code (IaC), la más conocida de todas es Terraform; estas herramientas nos permiten evitar la complejidad de las plantillas ARM.
Sin embargo, para los que trabajamos con Azure con cada actualización de la plataforma tenemos q esperar a que los proveedores de dichas herramientas realicen la implementación de los cambios y mejoras.
Para esto en el Ignite 2020 se presentó el proyecto Bicep, el cual fue formalmente presentado 1 año después en el Ignite 2021. Este proyecto al ser del propio Microsoft cubre todos los planes de soporte de Azure y nos permite compilar directamente los archivos bicep a plantillas ARM en JSON. Otra promesa que respalda Microsoft es que todas las características nuevas que se agreguen a la plataforma de Azure estarán disponibles en Bicep al mismo tiempo que sean liberadas.

Objetivo de Bicep

Al ser un DSL (Domain-Specific Language) su objetivo es simplificar la experiencia en las plantillas ARM con una sintaxis más limpia, modulable y reutilizable para desplegar los recursos de Azure.

Ventajas

Compatible con todos los recursos y versiones de API.
Sintaxis simple
Resultados repetibles
Orquestación
Modularidad
Integración con los servicios de Azure
Sin costo

Con Bicep no tenemos que utilizar otras herramientas para nuestros proyectos de IaC en Azure, no quiero decir que ya no las utilicemos si no simplemente tener una alternativa sólida para la el despliegue en la plataforma de Azure; además de las ventajas enumeradas tenemos el respaldo que esta proporcionando Microsoft de este lenguaje al hacer más fácil la gestión de las plantillas ARM sin depender de herramientas de terceros.

En las próximas entregas nos adentraremos más a Bicep. Espero que esta breve introducción haya despertado interés sobre esta alternativa para IaC.

SOLID - Los principios del diseño orientado a objetos - 1 er principio

Victor Canseco Soto — Tue, 09 Nov 2021 19:25:46 +0000

SOLID - Los principios del diseño orientado a objetos

Introducción

SOLID es un acrónimo de los primeros cinco principios del diseño orientado a objetos, los cuales fueron definidos por Robert C. Martin.

Estos principios establecen mejores practicas para el desarrollo de software con toda la complejidad que implica mantener y extender conforme el proyecto crezca. Al adoptar estas practicas también se elimina (o minimiza) el código basura, el refactorizar y nos permite utilizar metodologías agiles y/o adaptativas de desarrollo de software.

SOLID significa:

S - Single-responsiblity Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

A continuación abordaremos cada uno de estos principios para entender como estos cinco principios pueden ayudarte a ser un mejor desarrollador de software.

Single-responsiblity Principle

Este principio establece lo siguiente:

Una Clase debe tener una y solo una razón para cambiar, lo cual significa que una clase debe tener solo un trabajo.

Por ejemplo, consideremos una aplicación que utiliza una colección de figuras (círculos y cuadrados), la cual calcula la suma de el área de todas las figuras de la colección.

Primero creamos las clases de las figuras, su constructor y sus propiedades para inicializarlas.

Para los cuadrados necesitamos la longitud de uno de sus lados: Length

internal class Square
{
    public int Length { get; set; }
    public Square(int _length)
    {
        Length = _length;
    }
}

Para los círculos necesitamos conocer el: Radius

internal class Circle
{
    public int Radius { get; set; }
    public Circle(int radius)
    {
        Radius = radius;
    }
}

Después de crear las clases, continuamos con la lógica para la suma de las áreas de todas las figuras. Para esto recordamos algo de geometría básica.

Para calcular el área de un cuadrado: a = l * l

El área de un circulo se calcula de la siguiente forma: a = π * r^2

class AreaCalculator
{
    public List<object> Shapes { get; set; }
    public AreaCalculator(List<object> _shapes)
    {
        Shapes = _shapes;
    }
    public double Sum()
    {
        double Area = 0;
        foreach (var shape in Shapes)
        {
            if (shape is Square)
            {
                Area += Math.Pow(((Square)shape).Length, 2);
            }
            else
            {
                Area += Math.PI * Math.Pow(((Circle)shape).Radius, 2);
            }
        }

        return Area;
    }
    public void Print() 
    {
        Console.WriteLine($"La suma de las áreas de las figuras es: {Sum()}");
    }
}

Ahora llego la hora de integrar todo y probar

class Program
{
    static void Main(string[] args)
    {

        List<Object> Shapes = new List<object>
        {
            new Circle(2),
            new Square(5),
            new Square(6)
        };

        var Areas = new AreaCalculator(Shapes);

        Areas.Print();
    }


}

El problema con el método de impresión es que el controla la lógica de la salida de los datos.

Consideremos un escenario en el que la salida necesita ser convertida a otro formato como puede ser JSON.

Toda esta lógica podría ser manejada por esta clase; sin embargo esto violaría el principio de Single-Responsibility. Nuestra clase AreaCalculator solo debe de preocuparse por la suma de las áreas de las figuras, no le interesa si el usuario desea usarlas en JSON, HTML u otro formato de salida.

Para manejar esto debemos crear una clase separada la cual manejará la lógica que necesitamos para la salida de los datos para el usuario.

class CalculatorOutputter
{
    public AreaCalculator Calculator { get; set; }
    public CalculatorOutputter(AreaCalculator calculator)
    {
        Calculator = calculator;
    }
    public string ToJson()
    {
        return JsonSerializer.Serialize(Calculator.Sum());
    }
    public string ToHtml()
    {
        return $"La suma de las áreas de las figuras es: {Calculator.Sum()}";
    }

}

Integramos todo para utilizar la nueva clase y quedaría de la siguiente forma:

class Program
{
    static void Main(string[] args)
    {
        List<Object> Shapes = new List<object>
        {
            new Circle(2),
            new Square(5),
            new Square(6)
        };

        var Areas = new AreaCalculator(Shapes);
        var Salida = new CalculatorOutputter(Areas);

        Console.WriteLine(Salida.ToJson());
        Console.WriteLine(Salida.ToHtml());

    }
}

Con esto la lógica que necesitamos para la salida de datos para el usuario queda implementada en la clase CalculatorOutputter con lo cual satisfacemos el principio de Single-Responsibility.

Clean Code Tips - Usar nombres significativos

Victor Canseco Soto — Fri, 05 Nov 2021 03:15:52 +0000

Clean Code Tips - 01

Usar nombres significativos

Hola, bienvenidos a este nuevo blog. Comenzaré con uno de los puntos más difíciles al momento de comenzar a programar y es el Poner nombre a tus variables, clases, arreglos, etc.

Y vaya que es un martirio comenzar a ponerles nombre, sin embargo uno de los primeros tips para tener un código limpio y claro es nombrar correctamente cada elemento que se utilice.

Para ello no te quiebres la cabeza cuando recien empiezas a codificar. Los expertos recomiendan que primero escribas el codigo como va, sin importar los nombres; puesto que en este proceso no se tienen claras las ideas y mucho menos tienes visible todo el alcance del codigo.}

Así que primero codifica como gustes.

public static string Get(string input)
{
  char[] arr = new char[input.Length];
  int i = input.Length - 1;
  foreach (var e in input)
  {
    arr[i] = e;
    i--;
  }

  return new String(arr);
}

Ya que tengas todo claro, ahora si dedicate un tiempo a revisar y a nombrar cada uno de:

Clases
Metodos
Parametros
Variables
Librerias
Namespaces

 public static string GetReversedString(string originalString)
{
  char[] reversedChars = new char[originalString.Length];
  int currentIndex = originalString.Length - 1;
  foreach (var currentChar in originalString)
  {
    reversedChars[currentIndex] = currentChar;
    currentIndex--;
  }

  return new String(reversedChars);
}

Lamentablemente tal vez nunca seamos expertos para nombrar cada seccion de nuestro codigo, triste pero cierto.

Muchos de ustedes se preguntaran para que perder tiempo limpiando y refactorizando mi codigo, si yo le entiendo y con eso basta!; ese es uno de los errores mas graves que cometemos como programadores.

Sin embargo este tiempo lo podemos considerar una inversion