Descargar para leer sin conexión
Subido porCristiano Rafael Steffens
G xserver curso-actualizgxxev1
GeneXus Server permite a los desarrolladores trabajar de forma colaborativa en una base de conocimiento centralizada alojada en un servidor. Cada desarrollador puede enviar cambios a la base de conocimiento central mediante la operación "Commit to Server" y recibir actualizaciones de otros desarrolladores usando la operación "Update from Server". El servidor mantiene versiones y control de cambios de la base de conocimiento para facilitar la integración colaborativa.
G xserver curso-actualizgxxev1
- 1.
- 2. Definición Es unproducto diseñado para centralizar la KB y facilitar el trabajo en equipo, aún cuando sus integrantes se encuentren en diferentes puntos geográficos. • Ambiente de desarrollo aislado • Servicio de comunicación Cada desarrollador trabaja sobre su propia copia de la KB, que está conectada a una copia centralizada de la misma KB administrada por GXserver. Características generales
- 4. Send Knowledge Baseto Server Operación que se utiliza para publicar en el server una KB local. Luego de ser “enviada”, la KB queda disponible para que otro usuario se conecte a ella. • GxTechnical • Local Envío de una Knowledge Base
- 5. Knowledge Base fromServer Es la primera operación que el desarrollador debe completar para suscribirse a una KB hosteada en un servidor GeneXus. GXserver URL Seleccionar: • Knowledge Base • Versión de desarrollo en dicha KB La KB creada será una copia exacta de la KB en el server. Conexión a una Knowledge Base
- 6. Provee el mecanismopara interactuar con una instancia de GXserver. Opciones: • Commit To Server • Update From Server • What’s New? • Security Knowledge Manager / Team Development
- 7.
- 8. Commit to ServerEs la operación utilizada para actualizar la KB hosteada en el server. Para ver el conjunto de objetos que sufrieron cambios. Se debe agregar un comentario indicando el significado de los cambios. Envío de modificaciones Commit parcial Selección de objetos a enviar Para enviar al server las propiedades de la KB que sufrieron cambios.
- 9. Commit to ServerEs la operación utilizada para actualizar la KB hosteada en el server. Envío de modificaciones
- 10.
- 11. Update from ServerEs la operación que se debe ejecutar cada vez que se desea recibir los cambios que otros desarrolladores realizaron sobre la KB hosteada. Recibe todas las modificaciones en la KB local. Muestra las nuevas definiciones Recepción de modificaciones Para actualizar también las propiedades que cambiaron.
- 12. Revert de objetos Posibilidadde deshacer todas las modificaciones realizadas a un objeto desde la última sincronización exitosa con el server.
- 13. Integración de loscambios
- 14.
- 15.
- 16. Se puede volvera la anterior…
- 17. What’s New? Permitevisualizar los commits que se han realizado desde la última actualización. ¿Qué hay de nuevo en el Server?
- 18.
- 20. Ciclo de Vidade la KB
- 21.
- 22. Seguridad: Roles yPermisos Permisos a nivel del Server ManageSecurity ManageUserControls ManageExtensibility ManagePatterns Publish Permisos a nivel de la KB View Update Commit ViewDocumentation EditDocumentation ManageSecurity ManageVersions Delete Roles: Admin KB Admin KB User Server Guest
- 23. Seguridad: Roles yPermisos Por defecto… Rol Admin: Todos los permisos habilitados, tanto a nivel del server como de la KB. Rol KB Admin: Server Publish KB View KB Update KB Commit KB ViewDocumentation KB EditDocumentation KB ManageSecurity KB ManageVersions KB Delete Rol KB User: Server Publish KB View KB Update KB Commit KB ViewDocumentation KB EditDocumentation Rol Server Guest: Server Publish
- 24. Disconnect from Server Operaciónpara desconectar una KB local del server. Nuevamente queda habilitada la operación Send Knowledge Base to Server en el menú File.
- 25. Eliminación de unaKB Se elimina la KB del server.
Notas del editor
- #2 GeneXus Server es un producto diseñado para facilitar el trabajo en equipo. Permite que el conocimiento del negocio esté centralizado y que el trabajo de los integrantes del equipo de desarrollo esté constantemente integrado, aún si sus integrantes se encuentran en diferentes puntos geográficos Tener una KB central administrada por GeneXus Server permite que cualquier desarrollador autorizado, pueda enviar y recibir modificaciones desde su propìo lugar de trabajo. Durante el proceso de desarrollo de software se hace necesaria la interacción entre los desarrolladores. Pero esta interacción no es permanente. Muchas veces sucede que un desarrollador necesita aislarse para comprender o corregir cierta funcionalidad. Luego de finalizado ese proceso debe hacer públicos sus cambios y a la vez debe tomar cuenta de los cambios que realizaron otros desarrolladores. Y entonces el ciclo vuelve a repetirse. Es para facilitar la implementación de dicho ciclo que GeneXus Server provee un entorno de desarrollo aislado y servicios de comunicación. Cada desarrollador trabaja sobre su propia copia de la KB (aislada), que a su vez está linkeada a una copia centralizada de la misma KB administrada por GeneXus Server (servicio de comunicación)
- #3 Usando GXserver cada desarrollador tiene una KB personal y sus ventajas (performance, status de la KB conocido sin cambios producidos por modificaciones de otros desarrolladores, etc) y a su vez la solución completa está siendo construida en el servidor. A su vez se tienen otras ventajas: Agregar un desarrollador es simplemente "enrolarlo" al servidor, el status de la solución es bien conocido y fácilmente accesible, existen servicios RSS que permiten que no solo los desarrolladores involucrados en el proyecto reciban la información del mismo sino cualquiera que tenga acceso a dichos servicios, etc.
- #4 Cuando comienza un proyecto un desarrollador crea la KB y la envía al server desde la opción Send KB to server. El resto del equipo de desarrollo, realiza la operación New Knowledge Base from server para quedar conectados con el server y poder comenzar a trabajar. Aquí vemos solamente 2 desarrolladores pero la idea es que sean equipos desde 1 desarrollador, hasta equipos de 10, 20 o 30 desarrolladores los que lo usen.
- #5 La KB es ahora servida por la instancia del Gxserver seleccionada, y de esta forma otros usuarios podrán conectarse a ella. Además, es importante observar que a partir de este momento la KB local estará linkeada a la KB que se encuentra en el server. Esto significa que el desarrollador podrá formar parte de un ambiente de trabajo en equipo, actualizando y enviando sus cambios.
- #6 La KB creada será una copia fiel de la KB hosteada por el server. Luego de finalizado este proceso la conexión con el server finaliza, y el desarrollador podrá trabajar off-line (no conectado).
- #7 A través de este diálogo se puede interactuar con una instancia del GXserver. Las acciones posibles a realizar son las siguientes: Commit To Server: Oeración para modificar la KB hosteada. Update From Server: Operación para recibir los cambios que otros desarrolladores realizaron sobre la KB hosteada. What’s New?: Permite visualizar los commits que se realizaron desde la última actualización. Security: Permite definir/chequear la conexión con el server, indicando forma de autenticación, usuario y contraseña.
- #9 Cada desarrollador trabaja sobre una copia personal de la KB (no se requiere conexión alguna y no hay interacción en esa instancia entre los desarrolladores). Cuando el desarrollador decide que alguna funcionalidad está completa y quiere compartirla (agregarla a la solución completa) hace el correspondiente "commit" de dichas modificaciones. Cuando un desarrollador ejecuta una operación de "commit" los cambios hechos a su KB personal (objetos modificados, removidos o agregados) son enviados al server. En el server este conocimiento es consolidado con el existente y se le da "feedback" al desarrollador que está ejecutando la operación. El envío de las modificaciones puede ser parcial. No es necesario enviar siempre todas las modificaciones realizadas sino que se pueden seleccionar los objetos a enviar (commit parcial). Cuando se realiza una operación de commit, se debe agregar un comentario. Este comentario pasará a formar parte del log en el server. El botón Recent Comments despliega una ventana con los últimos comentarios ingresados.
- #10 Ignored Objects Muchas veces sucede que un desarrollador tiene en su KB local objetos de prueba o que aún no han sido finalizados y testeados. En estos casos no es deseable que dichos objetos se visualicen dentro de la lista de objetos a ser enviados al server (commit), y por lo tanto se deben enviar a la lista de objetos a ser ignorados en las operaciones de commit. Para enviar un objetos a la lista de objetos ignorados, alcanza con hacer click con el botón derecho del mouse sobre el objeto (desde la solapa Ready for Commit), y seleccionar “Add to ignore on Commit list”. Una vez que el objeto está terminado y listo para ser enviado al server (commit), se debe eliminar de la lista de objetos ignorados. Para esto, alcanza con hacer click con el botón derecho del mouse sobre el objeto (desde la solapa Ignored Objects), y seleccionar “Remove from Ignore on Commit list”.
- #12 La operación de "update" es de algún modo la contraparte de la operación de "commit". Aplica a la KB personal del desarrollador que la está ejecutando, todos los cambios realizados por otros desarrolladores en la KB del servidor, dándole feedback al desarrollador del resultado de dicha operación.
- #13 La operación Revert, permite deshacer todos los cambios realizados sobre un objeto desde la última sincronización exitosa con el server. En definitiva, es hacer que un objeto que aparece en la lista Ready for Commit, deje de estarlo. Esta opción aparece disponible haciendo click con el botón derecho del mouse sobre un objeto desde la lista Ready for Commit. Se setea como activa (SetAsActive) la versión correspondiente, sin que se pierda nada de la historia del objeto.
- #14 Dos desarrolladores trabajando sobre la misma KB, parten del mismo estado, solo con las TRNs de Clientes, Facturas y Compañia. Eventualmente pueden estar trabajando desde sus casas y hasta desconectados, ya que no se requiere conexión, salvo cuando tengan que integrar sus cambios . Los 2 parten de la KB AjaxSampleDemo, que tiene solamente la TRN de Client, Invoice y Company. Cada uno comienza a trabajar en sus objetos: A Mary le toca la opción de crear paises y ciudades A Diego le toca la parte de productos Una vez que cada uno termina su parte, desde la opción Knowledge manager / Team development, en la ventana de commit ven los cambios que deben enviar a GXserver para integrar el conocimiento. De esa forma realizan el commit y envian sus objetos al server. Luego si quisieran quedar actualizados con lo que el otro desarrollador envió al server, pueden hacer update. Mary puede hacer update para obtener los cambios de Diego (TRN Productos). Si vamos al server es posible ver como quedó integrado todo en la misma KB.
- #15 Veamos cómo enviar los cambios al server, y cuál es el comportamiento cuando dos usuarios modifican el mismo objeto. Ejemplo : Ambos usuarios parten de la misma TRN Company: Diego le agrega 2 atributos: CompanyAddress y CompanyPhone. Mary le agrega CountryId y CountryName Diego hace commit, y se envían sus cambios al server Mary hace commit, y aparece una advertencia porque no tiene la última versión de la TRN (ya que Diego la modificó), así que debe sincronizarse primero
- #16 Cuando Mary se sincroniza, automáticamente se realiza un Merge con los cambios que vienen del server y los cambios que ellla había hecho en la TRN. Por lo tanto obtiene una versión con todos los cambios integrados. Ahora sí puede enviarlos al server para integrar todos los cambios en la KB En este ejemplo cada usuario modificó la misma TRN, pero diferentes atributos. ¿Cuál sería el comportamiento si se modifica el mismo atributo?
- #17 Por ej, si ambos usuarios modificaron el atributo CompanyAddress, al momento de realizar la operación de update, Mary recibirá un mensaje indicando que dicho atributo fue modificado y será sobreescrito por el que se encuentra en el server. Podrá ver con detalle cuál fue el cambio que se realizó en el atributo, y en caso de decidir mantener sus propios cambios podrá consultar las revisiones del atributo y volver a la versión que tenía su propio cambio. Ningún cambio se pierde y en todo momento se puede decidir cuál es la versión correcta de los objetos y qué es lo que se quiere enviar al server.
- #18 Se puede recurrir a esta sección cada vez que se desea saber los cambios que han sido enviados al server (commits) desde la última actualización.
- #19 Una vez realizados los cambios, es posible ver directamente en Gxserver como quedó finalmente la KB con todos los cambios integrados. Esto se realiza desde el Visualizador de KBs. Al tratarse de una aplicación Web, lo único que necesita es un browser para poder ser utilizada, sin la necesidad de tener licencias GX. Por ejemplo, la podría usar el jefe del proyecto desde un hotel, o mostrarles a algunos empresarios como se va avanzando con el proyecto. Esto permite ver el estado de la KB, todos los objetos, cuáles fueron los últimos cambios, ver la documentación asociada a la KB, e inclusive modificar la documentación desde ahí mismo. También se puede ver la actividad de la KB, los últimos cambios. Es posible extender las funcionalidades de GXserver, a través del mismo mecanismo de extensibilidad de GeneXus.
- #20 Desde este Visualizador se podrá, entre otras cosas: Tener información general y gráfica de la KB (cantidad de objetos, objetos nos refernciados, etc) Tener una visión total de la KB: Podrá consultar todos los objetos (estructura, forms, reglas, eventos, variables), propiedades, etc. Editar la documentación (Main Document): Cuando posteriormente el desarrollador realice una operación de update, tendrá dicha documentación actualizada en la copia local de su KB. Tener un listado con las revisiones. Consultar configuraciones: Extensiones, User Controls (inclusive agregar user controls), Patterns, Indexer Monitor. Consultar el status de la licencia de GeneXus Server: Cantidad de días restantes, ingreso de autorización, etc. Eliminar una KB.
- #21 Otra cosa que permite el visualizador de KBs es llevar el ciclo de vida de la KB, definiendo allí las versiones que se van necesitando. En esta pantalla se ve la línea principal de desarrollo. Las versiones congeladas representan liberaciones del producto, y a su vez líneas paralelas de desarrollo (por ejemplo para corregir errores). De esta forma, al realizar la operación Create KB from server, se van a ver todas las versiones que hay en ella, y se podrá elegir sobre cuál hacer dicho create. Cada KB de GeneXus quedará conectada a una versión del server.
- #22 GeneXus Server se instala por defecto sin habilitar los seteos de seguridad. Para habilitarlos se deberá marcar la casilla de verificación “Secure Instance” durante el proceso de instalación. De esta forma, el server pedirá identificación cada vez que se intente conectar a él. Cuando se tiene una instancia segura del server, será necesario tener un certificado SSL ya que la comunicación entre GeneXus y el server se realiza por HTTPS. Por defecto existen dos métodos de autenticación: Local : El usuario por defecto es “admin”, password “admin123”. En el tab Security de GeneXus Server es posible modificar este usuario, agregar nuevos usuarios y definir roles y permisos. Gxtechnical Luego se puede definir la autorización. Esto se logra definiendo usuarios y autorizándolos sobre las distintas KBs. Se pueden definir usuarios a nivel de todo Gxserver o a nivel de KB. Finalmente, desde GX se utilizará la seguridad al realizar las operaciones Send KB to Server, Create KB from Server, y para todas las acciones: commit, update.
- #23 En las instancias de seguridad de GXserver es posible definir usuarios, roles y permisos. Cada server tiene un rol por defecto. Los usuarios que no tienen ningún rol asignado, toman dicho rol por defecto. Algunos roles pueden ser definidos durante el proceso de instalación del server, pero también es posible definir luego nuevos roles. Cada usuario puede tener diferentes roles, y a su vez, cada rol puede tener varios permisos. Hay permisos que aplican a todo el server, y otros que aplican a una KB específica. Permisos sobre el server: ManageSecurity: Permite adinistrar permisos y roles de todos los usuarios. ManageUserControls: Permite instalar y desinstalar User Controls. ManageExtensibility: Permite instalar y desinstalar Extensiones. ManagePatterns: Permite instalar y desinstalar Patterns. Publish: Permite enviar una KB al Server. Al usuario que realiza esta operación se le asigna el rol KBAdmin. Permisos sobre una KB: View: Permite visualizar la KB. Update: Permite realizar un Checkout (CreateKBfromServer), y obtener actualizaciones de la KB. Commit: Permite enviar modificaciones al server (operación Commit). ViewDocumentation: Permite ver la documentación de la KB ustilizando la interfaz web. EditDocumentation : Permite editar la documentación de la KB utilizando la interfaz web. ManageSecurity: Permite administrar roles y permisos de todos los usuarios de la KB. ManageVersions: Permite adinistrar versiones de la KB utilizando la interfaz web. Delete: Permite eliminar la KB utilizando la interfaz web (no la elimina físicamente sino que la elimina del catálogo de KBs publicadas).
- #24 Por defecto, los cada rol tiene los siguiente permisos habilitados: Admin: Todos los permisos habilitados tanto a nivel del server como de la KB. KB Admin: Tiene habilitados los permisos Server Publish, KB View, KB Update, KB Commit, KB ViewDocumentation, KB EditDocumentation, KB ManageSecurity, KB ManageVersions, KB Delete. KB User: Tiene habilitados los permisos Server Publish, KB View, KB Update, KB Commit, KB ViewDocumentation, KB EditDocumentation. Server Guest: Tiene habilitado solamente el permiso Server Publish.
- #25 Para desconectar una KB local de un server, se deberá ejecutar la operación Disconnect from Server. Desde la vista Preferences, al editar las propiedades de la KB, se encontrará la opción Disconnect from Server. Esto hace que dicho usuario desconecte su KB locar del server y pueda publicarla en otro server. Al confirmarse el mensaje, automáticamente vuelve a quedar habilitada la operación Send Knowledge Base to Server desde el menú File. La KB que se desconecta NO se puede volver a reconectar, pero sí se puede enviar nuevamente al server.
- #26 Para eliminar una KB del server bastará con deslizar el mouse sobre su nombre y aparecerá la opción Remove. Esta operación no elimina físicamente la KB sino que solamente la borra del catálogo de KBs publicadas en el server.