[#ALM] Deploy applications to #AZURE from #DropBox (what !?!?!)


image

Good,

although increasingly cost me more to catch me on what news of MS is concerned, today when I start to slowly Digest this news changed me the location ribs:

Now you can publish apps to AZURE since new repositories as Mercurial,GitHub … and Dropbox (if you read well, DROPBOX!)

The first thing I think is, what the ? SkyDrive this steroid on the list of possible sources for a publication of an AZURE app? and get me a chill that leaves me sitting staring at the floor. I personally use a lot SkyDrive, and I have my DropBox account where I keep guitar lyrics by the fact to be able to sync it directly a while ago with my Kindle Fire (now SkyDrive this already gives me everything and much better)

Although of course, before saying nothing better try it and see that scenarios are those who are covered by this, we all know that the spring water which comes down from the mountains and that take people from Redmond has unique properties that make that very few times they mistake. That said, I put hands to work:

image

And then I do something that I wonder:

1. Copy the output of a WebApp to a directory of SkyDrive DropBox. Default syntax is somewhat similar to Dropbox\Apps\ < Azure >. Behind the synchronization of these files is released

2 Access to the Azure portal and press the “Sync” button

3 Done!

Impressive, I already start to think about Continuous Deployment environments with a server’s Build enclosed within a Faraday cage.

In addition there is a 2-minute video explaining the step by step, where up to those that we never got to an IQ of 34 can understand it.

Source: http://weblogs.asp.net/scottgu/archive/2013/03/18/windows-azure-new-hadoop-service-html5-js-cors-phonegap-mercurial-and-dropbox-support.aspx

Saludos @ La Finca

El Bruno

image image image

[#ALM] Desplegar aplicaciones a #AZURE desde #DropBox (pero esto que es lo que es !!!)


image

Buenas,

si bien cada vez me cuesta más ponerme al día en lo que novedades de MS se refiere, hoy cuando comienzo a digerir lentamente esta noticia se me cambian las costillas de ubicación:

Ahora puedes publicar aplicaciones a AZURE desde nuevos repositorios como Mercurial, GitHub  …. y Dropbox (si leiste bien, DROPBOX !!!)

Lo primero que pienso es, ¿qué hace el SkyDrive con esteroides este en la lista de posibles orígenes para una publicación de una aplicación para AZURE? y me entra un escalofrío que me deja sentado mirando al piso. Yo personalmente uso mucho SkyDrive, y tengo mi cuenta de DropBox donde guardo letras de guitarra por el hecho de poder sincronizarla directamente hace un tiempo con mi Kindle Fire (ahora SkyDrive ya me da todo esto y mucho mejor)

Aunque claro, antes de decir nada mejor probarlo y ver que escenarios son los que se cubren con esto, todos sabemos que el agua manantial que baja de las montañas y que toman la gente de Redmond tiene propiedades únicas que hacen que pocas veces se equivoquen. Lo dicho, me pongo manos a la obra:

image

Y luego hago algo que me maravilla:

1. Copio el output de una WebApp a un directorio de SkyDrive DropBox. Por defecto la sintaxis es algo parecido a Dropbox\Apps\<Azure>. Por detrás se lanza la sincronización de estos archivos

2. Accedo al portal de Azure y presiono el botón “Sync”

3. Done !!!

Impresionante, ya comienzo a pensar en entornos de Continuous Deployment con un server de Build encerrado dentro de una jaula de Faraday.

Además hay un video de 2 minutos que te explica el paso a paso, donde hasta aquellos que no llegamos a un IQ de 34 podemos entenderlo.

Fuente: http://weblogs.asp.net/scottgu/archive/2013/03/18/windows-azure-new-hadoop-service-html5-js-cors-phonegap-mercurial-and-dropbox-support.aspx

Saludos @ Home

El Bruno

image image image

[#TFSERVICE] HowTo: Redeploy a release to a WebSite or CloudService specified in # Azure


image

Buenas,

have a couple of days I wrote a post where described as automate a deployment process using Team Build from TFS Preview for websites of Azure. This scenario is very cool, but of course, it can happen that given time we deploy this environment to a version that is not what we want to be online.

Well, in this case we can do is the following:

1. In the administration of AZURE portal we access our WebSite or Cloud Service

2 Access the “DEPLOYMENTS” section

3. In this section, we accede to the location by default where there are deployment (STAGING)

4. Then you will see a list with all deployments that have been made to this environment. If we want to redeploy a previous version, we must select the same.

5. Press the “REDEPLOY” button on the lower toolbar.

image

6 Done!

It is extremely simple and fairly straightforward to take into account Open-mouthed smile

Saludos @ La Finca

El Bruno

image image image

[#TFSERVICE] HowTo: Redesplegar una release especifica a un WebSite o CloudService en #Azure


image

Buenas,

have un par de días escribí un post donde describí como automatizar un proceso de despliegue utilizando Team Build desde TFS Preview para websites de Azure. Este escenario es muy chulo, pero claro, puede suceder que en deteminado momento despleguemos a este entorno una versión que no es la que queremos que esté online.

Pues bien, para este caso lo que podemos hacer es lo siguiente:

1. Dentro del portal de administración de AZURE accedemos a nuestro WebSite o Cloud Service

2. Accedemos a la sección “DEPLOYMENTS”

3. En esta sección, accedemos a la ubicación por defecto donde se realizan los despliegues (STAGING)

4. A continuación veremos un listado con todos los despliegues que se han realizado a este entorno. Si queremos redesplegar una versión anterior, debemos seleccionar la misma.

5. Presionar el boton “REDEPLOY” en la barra de herramientas inferior.

image

6. Done !!!

Es extremandamente simple y bastante sencillo para tenerlo en cuenta Open-mouthed smile

Saludos @ Home

El Bruno

image image image

[#TFSERVICE] Deploying applications # AZURE from Team Foundation Service 2012


image

Buenas,

today we are going with a simple example: create a web application and deploy it in AZURE directly with a build from Team Foundation Service. (another question that arose during ) the talk of Team Foundation Service SecondNug ).

So who here is a tutorial format which in the end is my personal help:

1. Create a project ASP.Net MVC 4. In my case it is a very simple that you browse and displays the following:

image

2. Protect our project in Team Foundation Service .

Note: If you don’t have an account, my post on how to create a free account to test Team Foundation Service can help you.

3. Download the .net development tools from the .Net Developer Center azure. In my particular case for Visual Studio 2012 RC, are also available for Visual Studio 2010.

image

4. The next step is to go to the AZURE portal to create a website that is where to deploy our ASP.Net MVC 4 website. The portal is accessed from http://manage.windowsazure.com/

5. The portal options we can create a new WebSite or a CloudService to deploy our solution. In this case create a new “Cloud Service” with the QUICK CREATE option and reserving the urlhttp://elbrunoLabs04.cloudapp.net .

image

6. Once the service is created, access to it and already we can integrate it with the corresponding TFS instance.

7. Select the option “INTEGRATE SOURCE CONTROL // Set up TFS publishing”

image

8 We authorize the Team Foundation Service account to the Cloud Service.

image

9 Select the Team Project from which it will post the changes to our Cloud Service

image

10. At this time, the process of Linking between TFS and Cloud Service is launched.

image

11 And in few seconds completes the Linkking between both

image

12. At this point we can already publish our content from Source Control of TFS Preview to our Cloud Service.

13. For this example, I added a new Cloud project to the solution and I’ve added a WebRole from ASP.Net MVC 4 of solution (“ElBruno.MVC4.Labs02″) project

image

14. The next step is to let set up our project of Cloud so that you can publish to the cloud service that we have created. Although this process is much more complex and has many variants, the resumie in a few steps.

15 Select the Cloud project, display the shortcut menu and select the option “Publish”.

16 Set the steps for publishing in the first place, we chose the subscription of AZURE we want to use.

Note: you can read the complete step by step here .

image

17. Below we define the settings of our application. In my case I will leave the values by default, since I do not need or Remote Desktop, or IntelliTrace, etc.

image

18. Finally complete the publication to AZURE with the data by default and launched the publishing process.

image

19. The publishing process usually takes between 2 and 10 minutes to a Cloud Service.

image

20. In a few minutes we will have the active application on AZURE directly deployed from Visual Studio.image

21. Now, the idea with this exercise is have a definition of Team Build Service that directly publish the changes that are uploaded to Team Foundation Service Cloud service that we have created.This will create a new definition of build in Team Foundation Service and the same configure what you describe in the following steps.

22. In the first place, I will work with a build called “elbrunoLabs04_CD”.

23. Then we can define if the Build is for continuous integration or launch it manually, in this case, and as we have no fear of anything, will leave it in mode IC. (that translated into AZURE it allows us to make Continuous Deployment)

24. Once the Workspace defined and the Default build options, arrived at one of the most important points of this post: the ability to use a template specific to AZURE Build. At this point, we select the Build Process Template called AzureContinuousDeployment.xaml

image

25. Once defined the solution to compile basic data and tests to run, we see that we have 2 special for AZURE sections. We define the name of the settings of deploy, we have put in the 16 to 18 steps and except that need to make an override another value, the build definition would already be complete.

image

26. Starting at this time, each time that we protect a file will launch a new process of Build that automatically display the changes towards the azure portal.

image

And ready, almost 30 steps then already we can deploy our applications directly using Team Build in TFS Preview to AZURE Open-mouthed smile

Saludos @ La Finca

El Bruno

image image image

 

[#TFSERVICE] Desplegando aplicaciones #AZURE desde Team Foundation Service 2012


image

Buenas,

hoy vamos con un ejemplo simple: crear una aplicación web y desplegarla en AZURE directamente con una build desde Team Foundation Service. (otra de las preguntas que surgió durante la charla de SecondNug de Team Foundation Service).

Asi que aquí va un formato tutorial que al final es mi ayuda personal:

1. Crear un proyecto ASP.Net MVC 4. En mi caso es un muy simple que se navega y muestra lo siguiente:

image

2. Protegemos nuestro proyecto en Team Foundation Service.

Nota: Si no tienes una cuenta, mi post sobre como crear una cuenta gratuita para probar Team Foundation Service te puede ayudar.

3. Descargamos las herramientas de desarrollo para .Net desde el .Net Developer Center de AZURE. En mi caso particular para Visual Studio 2012 RC, también están disponibles para Visual Studio 2010.

image

4. El paso siguiente consiste en ir al portal de AZURE para crear un website que es donde desplegaremos nuestro sitio web ASP.Net MVC 4. El portal se accede desde http://manage.windowsazure.com/

5. En las opciones del portal podemos crear un nuevo WebSite o un CloudService para desplegar nuestra solución. En este caso crearé un nuevo “Cloud Service” con la opción QUICK CREATE y reservando la url http://elbrunoLabs04.cloudapp.net.

image

6. Una vez creado el servicio, accedemos al mismo y ya podremos integrar el mismo con la instancia de TFS correspondiente.

7. Seleccionamos la opción “INTEGRATE SOURCE CONTROL // Set up TFS publishing”

image

8. Autorizamos la cuenta de Team Foundation Service al Cloud Service.

image

9. Seleccionamos el Team Project desde el que publicaremos los cambios a nuestro Cloud Service

image

10. En este momento se lanza el proceso de Linking entre TFS y el Cloud Service.

image

11. Y en pocos segundos se completa el Linkking entre ambos

image

12. En este punto ya podremos publicar nuestros contenidos desde el Source Control de TFS Preview hacia nuestro Cloud Service.

13. Para este ejemplo he agregado un nuevo proyecto de Cloud a la solucion y he agregado un WebRole a partir del proyecto de ASP.Net MVC 4 de la solución (“ElBruno.MVC4.Labs02”)

image

14. El siguiente paso es dejar configurado nuestro proyecto de Cloud para que pueda publicar al cloud service que hemos creado. Si bien este proceso es bastante más complejo y tiene muchas variantes dentro, lo resumie en pocos pasos.

15. Seleccionar el proyecto de Cloud, desplegar el menú contextual y seleccionar la opcion “Publish”.

16. Configuramos los pasos para la publicación en primer lugar, elegimos la suscripción de AZURE que queremos utilizar.

Nota: el paso a paso completo se puede leer aquí.

image

17. A continuación definimos las settings de nuestra aplicación. En mi caso dejaré los valores por defecto, ya que no necesito ni Remote Desktop, ni IntelliTrace, etc.

image

18. Finalmente completo la publicación a AZURE con los datos por defecto y lanzo el proceso de publicación.

image

 

19. El proceso de publicación suele tardar entre 2 y 10 minutos para un Cloud Service.

image

20. En pocos minutos ya tendremos la aplicación activa en AZURE directamente desplegada desde Visual Studio.image

21. Ahora bien, la idea con este ejercicio es tener una definición de Team Build Service que publique directamente los cambios que se suben a Team Foundation Service al Cloud Service que hemos creado. Para esto crearemos una nueva definición de build en Team Foundation Service y en la misma configuraremos lo que describo en los siguientes pasos.

22. En primer lugar voy a trabajar con una build llamada “elbrunoLabs04_CD”.

23. Luego podemos definir si la Build es para Integración Continua o para lanzarla manualmente, en este caso y como no le tenemos miedo a nada, la dejaremos en modo CI. (que traducido a AZURE nos permite hacer Continuous Deployment)

24. Una vez definido el Workspace y las opciones de build Default, llegamos a uno de los puntos más importantes de este post: la capacidad de utilizar una plantilla de Build específica para AZURE. En este punto seleccionamos la Build Process Template llamada AzureContinuousDeployment.xaml

image

25. Una vez definidos los datos básicos de la solución a compilar y los tests a ejecutar, vemos que tenemos 2 secciones especiales para AZURE. Definimos el nombre de las settings de deploy que hemos puesto en los pasos 16 a 18 y salvo que necesitemos hacer un override otro valor, la definición de build ya estaría completa.

image

26. A partir de este momento, cada vez que protejamos un archivo se lanzará un nuevo proceso de Build que automáticamente desplegará los cambios hacia el portal de azure.

image

Y listo, casi 30 pasos después ya podemos desplegar nuestras aplicaciones directamente utilizando Team Build en TFS Preview a AZURE Open-mouthed smile

Saludos @ Home

El Bruno

image image image

 

 

 

 

[# ALM] Continuous Deployment, here we go!


Hi,

Since a few days ago is being conducted an interesting discussion in Agile Spain groups about Continuous Deployment.While some of the entries are for autoafirmar that each is the best implementer of SCRUM that exists, or to explain the why of a practice such as continuous integration, there are many deserving read only by the fact of starting to change our way of thinking. First things first, and before it’s always: to achieve an environment with CD, need to have a 100% of management support, a very seamless integration between development teams and teams of systems, etc. etc. etc. In other words, this is a practice that requires a very high level of maturity in terms of practices is required. If you look for example at Wikipedia, the definition of Continuous Deployment does not exist, but if there is an invalid link from Continuous Integration.

What if it exists on Wikipedia is the concept of Continuous Delivery, explaining as applying the practices of Automated Testing, Continuous Integration and Automated Deployment is possible to mount a Continuous Deliveryenvironment. One of the principles of this practice is to accelerate the time of deploying an application to a specific environment, either a test or even production environment. In my case, leveraging the capabilities of Team Build 2010 and Azure that I can get this in the next project that I have in hand.

Note: the only major problem I have in vista now that I am planning to this model, is the limited capacity of deployment that has an environment like Windows Phone, let is a chestnut to automate this same. You ask the crack of Joshua Yeray (@ JosueYeray ) to see which recommends.

At this point, my working model will initially be based on 2 lines of development (with a very mature model of branching weAvanade Spain) where it will always be available (i.e. displayed) for testing

  • An environment with the application deployed from the last output of a build with a correct implementation (build + unit tests) of the line of development.
  • An environment of AZURE to TEST with the application deployed from the last output of a build of a branch that has passed a battery of tests of UX.

Obviously behind all this, will continue to apply Test Driven Development, ensuring a uniform syntax using StyleCop, ensuring control of projects through TFS and some good practice to define, etc. But come on, that in the end the idea remains the same:

Improve the way in which we develop software on a daily basis

image

When you have implemented and you can evaluate the results of implement and maintain this practice for a time, ´comentaré my impressions.

Greetings @ Home

The Bruno

Resources:

PS: Just buy the book at Amazon (http://bit.ly/zbiP9A) from just €28.

[#ALM] Continuous Deployment, alla vamos !!!


Buenas,

desde hace unos días se está llevando a cabo una discusión interesante en los grupos de Agile Spain sobre Continuous Deployment. Si bien algunas entradas son para autoafirmar que cada uno es el mejor implementador de SCRUM que existe, o para explicar el porqué de una práctica como integración continua, hay muchas que merece leer solo por el hecho de comenzar a cambiar nuestra forma de pensar. Primero lo primero, y antes lo de siempre: para lograr un entorno con CD, necesitas tener un apoyo 100% de la dirección, una integración muy fluida entre los equipos de Desarrollo y los equipos de Sistemas, etc. etc. etc. En otras palabras esta es una práctica que requiere un nivel de madurez muy alto en cuanto a prácticas se requiere. Si nos fijamos por ejemplo en Wikipedia, la definición de Continuous Deployment no existe, aunque si existe un link inválido desde Continuous Integration

Lo que si existe en Wikipedia es el concepto de Continuous Delivery, donde se explica como aplicando las prácticas de Automated Testing, Continuous Integration y Automated Deployment es posible lograr montar un entorno de Continuous Delivery. Uno de los principios de esta práctica es acelerar los tiempos de despliegue de una aplicación a un entorno específico, ya sea un entorno de test o inclusive de producción. En mi caso aprovechando las capacidades de Team Build 2010 y Azure que podré ponerme con ello en el próximo proyecto que tengo en manos.

Nota: El único gran problema que tengo en vista ahora que estoy planeando este modelo, es la poca capacidad de despliegue que posee un entorno como Windows Phone, vamos que es una castaña para automatizar esto mismo. Le preguntaré al crack de Josué Yeray (@JosueYeray ) para ver que recomienda.

En este punto, mi modelo de trabajo inicialmente se basará en 2 líneas de desarrollo (gracias a un muy maduro modelo de branching que tenemos en Avanade Spain) donde siempre estarán disponibles (es decir desplegado) para probar

  • Un entorno con la aplicación desplegada a partir del último output de una build con una ejecución correcta (build + unit tests) de la línea de desarrollo.
  • Un entorno de AZURE para TEST con la aplicación desplegada a partir del último output de una build de una rama que ha pasado una batería de pruebas de UX.

Obviamente detrás de todo esto, seguiremos aplicando Test Driven Development, asegurando una sintaxis homogénea utilizando StyleCop, asegurando el control de proyectos gracias a TFS y alguna buena práctica a definir, etc. Pero vamos, que al final la idea sigue siendo la misma:

Mejorar la forma en la que desarrollamos software diariamente

image

Cuando lo haya implementado y pueda evaluar el resultado de implementar y mantener esta práctica por un tiempo, ´comentaré mis impresiones.

 

Saludos @ Home

El Bruno

   

Recursos:

PD: Acabo de comprarme el libro en Amazon (http://bit.ly/zbiP9A) a tan solo €28.