SqlServer Management Tools + Warning about Saving changes is not permitted

The Save (Not Permitted) dialog box warns you that saving changes is not permitted because the changes you have made require the listed tables to be dropped and re-created.

The following actions might require a table to be re-created:

• Adding a new column to the middle of the table
• Dropping a column
• Changing column nullability
• Changing the order of the columns
• Changing the data type of a column

To change this option, on the Tools menu, click Options, expand Designers, and then click Table and Database Designers. Select or clear the Prevent saving changes that require the table to be re-created check box.

TFS: El build no termina nunca, corre por siempre

Alguna vez me pasó que el build llevaba un día entero colgado en la parte del publish de ClickOnce. 

Lo que sucedió es que por algún motivo una ventana de dialogo (pop-up) se abrio y quedo esperando (por siempre) a que alguien la cierre.

Me dí cuenta al loguearme al build server con la cuenta que corre el build. Otra forma de darse cuenta es checkeando el event log por errores/warnings.

Como es ClickOnce, lo que pudo ocurrir es que el certificado digital que necesitaba usar para firmar los manifiestos se halla importado/instalado con la opción de preguntar por la contraseña (primera opción). Simplemente hay que desinstalarlo y volverlo a importar como sugiere esta imagen:

Firmar assemblies y manifiestos de ClickOnce con Strong Name Keys

1. ¿Qué es un certificado digital?

Es una herramienta que se usa para verificar la integridad de los datos que se transmiten entre el origen (quien firma) y el destinatario (quien verifica). Los certificados o firmas digitales son creadas y verificadas utilizando criptografía de llave pública. Quien firma posee una un par de llaves criptográficas: una llave publica, que es usada para verificar que el firmante conoce la clave privada y el mensaje.

En algunos casos (como el que estamos viendo aquí), con ayuda de más infraestructura, podemos usar los certificados para saber y corroborar el nombre del que firma los mensajes, y asegurarnos además que el mensaje no ha sido alterado luego de que el firmante creara la firma para ese mensaje. Entre todos los mecanismos que existen para implementar las firmas digitales, Microsoft .NET utiliza para sus Strong Name el algoritmo RSA de clave publica y el algoritmo hash SHA-1.

Hay certificados de prueba y hay certificados reales firmados por autoridades de certificación (CAs) como por ejemplo Verisign. También se puede crear un certificado de prueba y luego hacerlo firmar por un CA.

2. ¿Qué es un Strong Name?

Es un mecanismo de Microsoft .Net para darle a nuestros assemblies una identidad única. La identidad está compuesta por:
* una clave pública (RSA)
* un nombre (texto del nombre del archivo - sin extensión - que contiene el assembly)
* versión (compuesta por cuatro partes: Major.Minor.Build.Revision. Ej: 10.0.0.1)
* certificado digital (contiene la clave privada)
* cultura (opcional)
* arquitectura del procesador (opcional)

Para obtener un Strong Name válido, nuestro assembly es firmado (strong-name signed) durante el proceso de build usando la clave privada que corresponde a la clave publica en el Strong Name. De esta forma la firma Strong Name puede ser verificada con la clave pública. Hay varias técnicas distintas para crear una firma Strong Name y para manejar la clave privada durante el firmado que explicaré más adelante.

Cuando un assembly hace referencia a un strong-named assembly, captura la información del strong name del assembly referenciado. Cuando el framework de .net intenta cargar un strong-named assembly, verifica la firma strong-name, si no lo puede hacer, entonces directamente no lo carga.

Una excepción a este proceso se da con strong-named assemblies que están en el Global Assembly Caché (GAC). Estos assemblies no son verificados cada vez que .Net los carga porque ya fueron verificados cuando se instalaron en el GAC. El GAC es un repositorio restringido con solo acceso a Administradores, con lo cual si ya fueron ingresados se entiende que ya es suficiente con haberlos validado en ese momento.

3. ¿Cuando deberíamos firmar con Strong Name keys nuestros assemblies?

Cuando necesitemos que nuestros componentes (dlls) tengan una identidad única (que nadie los pueda falsificar) y garantizar que nuestras dependencias se mapean correctamente con las versiones correctas.

El tema de falsificar la identidad del assembly tiene que ver con que alguien obtenga la clave privada (que deberíamos mantener.. privada!) y firme cualquier otro assembly o el mismo modificado con nuestra strong-name key y se haga pasar por nosotros. Tener un strong-name nos permite tomar ciertas decisiones respecto a seguridad como confiar en todos los assemblies firmados con nuestro strong-name dentro de nuestra intranet. Digo intranet porque una firma strong-name no nos asegura nada respecto del que firma (publisher), con lo cual no podriamos confiar en un strong-name de un assembly externo o de internet (salvo que tengamos un canal seguro desde donde obtener la clave pública de ese assembly, o sea, un CA!).

Típicamente firmamos DLLs, no EXEs. Firmar un EXE implica que no podrá referenciar DLLs que no esten firmadas con strong-name, y esto complica las cosas. En vez de esto se firman los manifiestos del EXE que apuntan a las DLLs que no están firmadas. Lo mismo sucede con DLLs firmadas con strong-name que referencian a otras DLLs que no están firmadas (ya sea nuestras o peor, de terceros), esto es un problema porque sí o sí todas las DLLs deberán estar firmadas con strong-name, sino no compilará nuestro proyecto.

Por otro lado tener los assemblies firmados complica el deployment. Por ejemplo si necesitamos hacer un bug fix en uno de nuestros assemblies, incrementando el numero de versión para ese assembly, provocará que la aplicación luego no encuentre el assembly (buscará el anterior). Para solucionar esto deberemos compilar la solución completa para ese assembly, peor aún si es un assembly compartido entre varias aplicaciones. Una alternativa en el caso que el assembly esté en el GAC sería usar las publisher policy para redirecionar el cargado de la version 1.0.0.0 a la version 1.0.0.1 (la del bug fix), pero esto sería complicar aún más las cosas. Finalmente podríamos no cambiar el numero de versión y la aplicación encontraría el assembly.

Como ven, firmar con strong-name añade complejidades y deberíamos evitar firmar con strong-name nuestros assemblies salvo que vayan a ser instalados en el Global Assembly Cache (GAC) o salvo que vayan a ser recursos compartidos (DLL) de otras aplicaciones. Firmarlos porque sí solo agrega más esfuerzo y problemas.

Para más detalle ver: Strong-Name Signing for Managed Applications.
http://msdn.microsoft.com/en-us/library/xwb8f617(v=vs.110).aspx#bypassing_signature_verification

4. ¿Qué es un certificado .pfx?

Significa Personal Information Exchange y es una strong name key (.snk) protegida por contraseña.

5. ¿Cuando deberíamos firmar los manifiestos de ClickOnce?

En ClickOnce, debemos firmar obligatoriamente los manifiestos. Esto se hace utilizando un archivo .pfx o un certificado de nuestro personal certificate store.

Si usamos el archivo .pfx debermos ingresar la contraseña del mismo para que pueda ser importado al personal certificate store.

6. ¿Como se firman las librerías y manifiestos de ClickOnce de nuestros proyectos a través de Visual Studio?

En las propiedades del proyecto que queremos firmar, si vamos a la solapa "Signing" encontraremos la página de configuración para firmar el proyecto. Ésta tiene dos secciones: Sign the ClickOnce manifests y Sign the assembly.
Referencias:

• Using Strong Name Signatures: http://msdn.microsoft.com/en-us/magazine/cc163583.aspx#S8
• http://msdn.microsoft.com/es-ar/library/aa730868(v=vs.80).aspx

KANBAN vs SCRUM

Quería compartir con  ustedes una breve comparación entre dos metodologías que están de moda estos últimos años. Ambas son ágiles, pero existen fundamentalistas de ambos lados, que dice que una es mejor que la otra. Entonces, ¿Cuál se adecuará mejor a tus proyectos? ¿Cuál es la tendencia mundial?

Antes que nada voy a hacer un breve repaso de ambas, para luego revisar las similitudes y diferencias para que podamos entender cuál es la mejor metodología:

Scrum en pocas palabras

• Divide tu organización en equipos pequeños, multidisciplinarios y auto-organizados.  
• Divide  el  trabajo  en  una  lista  de  entregables  pequeños  y concretos.  Ordena  la  lista  por  orden  de  prioridad  y  estima  el esfuerzo relativo de cada elemento. 
• Divide  el  tiempo  en  iteraciones  cortas  de  longitud  fija (entre 1  y  4  semanas),  con  código  potencialmente entregable y demostrado después de cada iteración. 
• Optimiza  el  plan  de  entregas  y  actualiza  las  prioridades  en colaboración  con  el  cliente,  basada  en  los  conocimientos adquiridos  mediante  la  inspección  del  entregable  después  de cada iteración.
• Optimiza  el  proceso  teniendo  una  retrospectiva  después  de cada iteración.

 Así  en  lugar  de  un  grupo  numeroso  pasando  mucho  tiempo construyendo  algo  grande,  tenemos  un  equipo  menor  pasando  un tiempo  más  corto  construyendo  algo  menor.  Pero  integrando  con regularidad para ver el conjunto.

Kanban en pocas palabras

• Visualiza el flujo de trabajo
• Divide  el  trabajo  en  bloques,  escribe  cada elemento en una tarjeta y ponlo en el muro.
• Utiliza columnas con nombre para ilustrar dónde está cada elemento en el flujo de trabajo.
• Limita  el  WIP  (Work  in  Progress,  trabajo  en  curso)  - asigna  límites  concretos  a  cuántos  elementos  pueden  estar  en progreso en cada estado del flujo de trabajo.
• Mide  el  lead  time  (tiempo  medio  para  completar  un elemento, "tiempo  de  ciclo"),  optimiza  el proceso  para  que  el  lead  time  sea  tan  pequeño  y  predecible como sea posible.

Kanban deja casi todo abierto. Las únicas normas son Visualiza tu Flujo de  trabajo  y  Limita  tu  WIP  (Work  In  Progress,  Trabajo  en  curso).  

¿En qué se parecen?

• Ambos son Lean y Ágiles:
• Tanto  Scrum  como  Kanban  son  sistemas  de  planificación  tipo "Pull", principio de gestión de inventario 'Just In Time' (JIT) propio de Lean. Esto significa que el equipo elige cuándo y cuánto trabajo acometer.  Ellos  (los  componentes  del  equipo)  "tiran"  del  trabajo cuando  están  listos,  en  contraposición  a  que  desde  el  exterior  se "empuje" al equipo a hacerlo. Al igual que una impresora tira de la siguiente página solo cuando esta lista para imprimir en ella (aunque tenga hojas de papel en la bandeja).
• Scrum y Kanban se basan en procesos de optimización continuos y empíricos, que se corresponden con el principio Kaizen de Lean.
• Scrum y Kanban dan más importancia a la respuesta al cambio que  al  seguimiento  de  un  plan  (aunque  Kanban  permite, típicamente,  una  respuesta  más  rápida  que  Scrum).  Uno  de  los cuatro principios del manifiesto ágil.  
• Ambos establecen límites WIP, Kanban lo limita por flujo de trabajo, Scrum por iteración (capacity).
• En ambos la visibilidad del proceso es la base de su mejora.
• Ambos tienen como objetivo la entrega temprana y frecuente de software.
• Ambos trabajan con equipos auto-organizados.
• Ambos necesitan la división del trabajo en partes.
• Ambos revisan y mejoran de forma continua el plan del producto en base a datos empíricos (velocidad / tiempo de entrega)

¿En qué se diferencian?

Scrum	Kanban
Iteraciones de tiempo fijo.	Sin iteraciones. La cadencia puede variar en funcion del plan de negocio y la mejora del proceso.
La métrica principal es la Velocidad (story points "done" por sprint).	La métrica principal es el Lead Time (tiempo medio que tarda una petición en salir del ciclo).
Equipos multifuncionales.	Sin restricciones, pueden ser multifuncionales o especializados.
El tamaño de las tareas no puede exceder la duración del sprint.	Sin restricciones, aunque se recomienda que todas sean de la misma longitud para tener mas previsibilidad.
Se utiliza el Burndown Chart como diagrama de seguimiento diario	No prescribe ninguno, aunque se recomienda el de Cumulative Flow Chart.
Se emplea una limitacion WIP indirecta (por sprint).	Se emplea una limitación WIP directa (por el estado del trabajo).
Se deben realizar estimaciones	Las estimaciones son opcionales.
No se pueden añadir tareas directamente en medio de una iteración. Hay que negociar con el dueño del Producto y el Equipo que se quita si se añade más trabajo. En general no está recomendado.	Siempre que haya capacidad disponible, se pueden añadir tareas.
El Backlog del sprint pertenece a un equipo determinado.	Varios equipos  pueden compartir la misma pizarra Kanban.
Se prescriben 3 roles (Product Owner, Scrum Master y Equipo).	No hay roles. Se pueden tener todos los roles que se considere necesario.
En cada sprint se limpia el sprint backlog.	El tablero de Kanban es persistente.
El Product Backlog debe estar priorizado.	La priorización es opcional, generalmente se priorizan los elementos próximos a desarrollarse.

¿Cuál es el mejor?

Todo depende del contexto en que lo uses. Por ejemplo, Scrum es lo ideal si se dan estas condiciones:

1. Posibilidad de tener una persona con suficiente tiempo de dedicación al rol de Product Owner (que tenga tiempo de tomar los requerimientos del cliente y escribir las historias de usuario; estar 100% disponible para el equipo de desarrollo; tiempo para mantener un Product Backlog priorizado y con suficientes historias de usuario detalladas para un sprint de trabajo; etc).
2. Scrum Master con disponibilidad 100% para el equipo, facilitando el trabajo de todos y quitando los impedimentos a tiempo.
3. Cantidad de trabajo suficiente de parte del cliente como para cubrir un sprint y que no queden tiempos muertos entre sprint y sprint.
4. Equipo de trabajo lo más auto-suficiente y auto-organizado posible, sin diferencias técnicas notables.
5. Los requerimientos son cambiantes, pero el cliente está más dispuesto a postponer el cambio a la siguiente iteración.
6. Estamos desarrollando un nuevo producto, lo cual implica un mínimos de trabajo suficiente para 3 meses y una mínima planificación de prioridades.

En cambio Kanban es más adecuado si por ejemplo:

1. La cantidad de trabajo de parte del cliente es muy fluctuante (a veces mucho, a veces no alcanza a la semana continua de trabajo) o la persona encargada de tomar los requerimientos al cliente (el PO en Scrum) tiene también otras asignaciones y su cadencia para llevar las peticiones al equipo de desarrollo es fluctuante.
2. El equipo de trabajo es demasiado especializado o con diferencias técnicas notables, donde se hace muy difícil la estimación del trabajo a realizar.
3. Los requerimientos son muy cambiantes o estamos en una fase de mantenimiento, donde el cambio debe llegar lo antes posible a producción y no podemos esperar a que termine un sprint.
4. Llevas múltiples productos al mismo tiempo. Kanban no discrimina entre productos, sino tareas en un flujo de trabajo.

Scrum es más restrictivo que  Kanban  ya  que  prescribe  cosas  como  iteraciones  y  equipos interdisciplinarios. Kanban está más cerca del "hace lo que quieras", si bien esto parece muy ágil, hay que tener en cuenta que la falta de límites también dificulta la gestión.

Si  haces  iteraciones  cada  vez  más  cortas, esencialmente te estás aproximando a Kanban. Una vez que se empieza a  hablar  de  hacer  durar  la  iteración  menos  de  una  semana,  se  debería considerar abandonar definitivamente las iteraciones a tiempo cerrado.

En cuanto a las reuniones diarias y las retrospectivas, recomiendo tenerlas en ambas metodologías.

¿Cuál es la tendencia?

Hasta el 2013, Scrum y sus variaciones (73%) siguen siendo las metodologías ágiles más populares. Kanban representa sólo el 5% aunque viene creciendo lentamente.

Final

Este tema da para hablar muchísimo más de lo que he puesto acá, si tenés alguna duda o algo para agregar no dudes en comentarlo. Tienes algún ejemplo o anécdota que quieras compartir?

Referencias

http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf