- Este debate tiene 6 respuestas, 3 mensajes y ha sido actualizado por última vez el hace 3 años, 7 meses por
ago.
duda con el nuemro de coedunit
-
agoParticipanteagoHola,
siguiendo el curso de testing veo que por cada extension hacen falta dos cu: test y testrunner
ademas haria falta otra codeunit para install/uninstall
ademas de la cu propia de la extension.
en total 4 CU
Solo hay disponibles 10 CU en una licencia normal on promise
Las 4 CU mencionadas cuentan como CU para el control de la licencia??
gracias
1 abril 2020 a las 11:29 #14832
Laura NicolàsSuperadministradorLaura NicolàsHola ago,
- En una licencia OnPremise de cliente, vienen 100 codeunits. (son las tablas, que vienen 10)
- Si se necesitan más, se pueden comprar nuevos paquetes de 100 unidades.
Se que lo de “comprar” objetos es un rollo, y si podemos lo intentamos evitar, pero lo he comentado porque no te tienes que sentir limitado por los 100. Si se necesitan más porque el proyecto lo requiere, sale mas barato comprar objetos, que hacer inventos para aprovechar los objetos que ya tienes, porque complicas el mantenimiento, que al final el tiempo y dinero.
- Para hacer testing necesitas -por lo menos- 1 codeunit de tipo test.
Si el proyecto es grande, y tienes distontos módulos, posiblemente te interesará separar los tests por módulos. En el proyecto en el que estamos nosotras ahora ya vamos por 13 codeunits de test. - En muchas ocasiones necesitas también librerías de test (en una codeunit a parte), para que te ayuden a crear los datos que necesitas para el test. En nuestro proyecto tenemos una librería para cada módulo, por lo que ya van otras 13 codeunits.
- Para hacer testing no necesitas crear una nueva testrunner. El estandard ya trae un testrunner y lo puedes usar.
A mi me gusta crear uno a parte, porque así voy mucho más rápida en ejecutar los tests ya que lo hago con PowerShell. Si ahorro tiempo, ahorro dinero (mucho más que el que cuesta la codeunit).
Así, en el proyecto en el que estamos nosotras ya vamos por 27 codeunits dedicadas al testing.
¿Cuentan para la licencia? Si y no. Depende.- Los tests, se deberían publicar únicamente en un entorno de test/desarrollo. Nunca en producción.
- Para ello, tenemos 2 extensiones. La primera contiene la funcionalidad, la segunda contiene los tests.
- En producción, publicamos solo la app que tiene la funcionalidad. Así, la licencia del cliente solo tiene que tener en licencia los objetos usados para la funcionalidad.
- En en entorno de test utilizo mi licencia de partner, por lo que no tengo limitaciones en las numeraciones.
- Si el cliente tuviera desarrolladores InHouse y necesitara un entorno de desarrollo con su licencia, entonces sí que necesitaría tener los objetos del test en licencia.
Y también estan, como decías, las codeunits de Install y las de Upgrade.
Y ahora en el ScaleUp 2020 hablaremos de las interfaces… que también usan muchas codeunits.En general, para una buena arquitectura -robusta y escalable- , es recomendable que cada objeto sirva para una cosa y solo una.
Terminas con muchos más objetos -que hay que comprar-, pero trabajas mucho mejor.Salut!
Laura Nicolàs1 abril 2020 a las 14:10 #14833
agoParticipanteagoHola,
dos cosas:
1.- se trata de BC130 en suscripción y como ves no nos deja mas que 10 codeunit. O hacemos algo mal?
2. en el curso de crear Json con extensiones, tienes todas las CU en la misma extensión. Quieres decir que para subir la extensión a producción haces una copia y quitas las cu de test o que tienes dos extensiones diferentes donde la de test esta con dependencia de la de producción?
muchas gracias
1 abril 2020 a las 19:13 #14836
Cristina NicolàsSuperadministradorCristina NicolàsYo creo que tienes compradas 10 codeunits adicionales, pero me parece que igualmente hay 100 que vienen por defecto pero que aquí no se ven.
Si sacas un informe detallado de la licencia se debería ver.O algo que hago yo a menudo es hacerme una página de la tabla “License Permission” y allí veo que números están en licencia y cuales no.
Un saludo,
Cristina Nicolàs2 abril 2020 a las 09:32 #14838
Laura NicolàsSuperadministradorLaura Nicolàs[quote quote=14836]2. en el curso de crear Json con extensiones, tienes todas las CU en la misma extensión. Quieres decir que para subir la extensión a producción haces una copia y quitas las cu de test o que tienes dos extensiones diferentes donde la de test esta con dependencia de la de producción?[/quote]
- El curso de Json lo empecé a grabar con BC14.
- En esta versión, gestionar la publicación de extensiones dependientes era completamente manual y muy tedioso, sobretodo cuando estás en fase de desarrollo, que estás publicando cada 5 minutos.
- Para no complicarme la vida con las dependencias, lo puse todo en una misma extensión.
- En un proyecto que hice con BC14, cuando finalicé el desarrollo separé los test de la app principal
A partir de BC15 tenemos gestión automatizada de la publicación con dependencias. Y esto cambia las reglas del juego por completo ,-)
- A partir de BC15, empiezo el proyecto creando dos extensiones separadas: una para la funcionalidad, otra para los tests.
- La extensión de los test tiene una dependencia con la extensión de la funcionalidad
- En Visual Studio Code creo un Workspace para poder tener abiertas las dos extensiones a la vez, en el mismo editor.
- Es a través de los Workspaces que AL sabe publicar y gestionar las dependencias de forma automatizada.
El tema de los workspaces no lo tenemos explicado en ningún curso (todavía).
Será una cosa que veremos en el ScaleUp 2020, y después lo colgaremos en la web.Salut!
Laura Nicolàs2 abril 2020 a las 11:49 #14847
Debe iniciar sesión para responder a este tema.