eclipse-plugin salesforce visualforce force.com

eclipse plugin - ¿Cómo pueden los desarrolladores múltiples trabajar eficientemente en una aplicación de force.com?



eclipse-plugin salesforce (6)

La empresa para la que trabajo está creando una aplicación de force.com administrada como una integración con el servicio que brindamos.

Tenemos problemas al trabajar simultáneamente en el mismo conjunto de archivos debido a las herramientas de mala calidad que se proporcionan con el complemento Eclipse de force.com. Si 2 desarrolladores están trabajando en el mismo archivo, a uno se le da un mensaje que no puede guardar. Una vez que se fusiona, tiene que forzar manualmente el complemento para enviar sus cambios al servidor y hacer clic en 2 "¿Está realmente seguro?" mensajes

Básicamente, el herramental realiza un trabajo de mala calidad al fusionar los cambios y obliga a los minutos de trabajo cada vez que el desarrollador desea guardar si otra persona ha modificado el archivo en el que está trabajando.

Actualmente estamos trabajando para solucionar esto básicamente ''bloqueando'' archivos individuales al permitir que los compañeros de trabajo sepan quién está editando un archivo.

Se siente como que tiene que haber una mejor manera en este día y edad. ¿Alguien sabe de un conjunto de herramientas diferente que podríamos usar, el proceso que podríamos cambiar o algo que podamos hacer para que esto sea más fácil?

Al trabajar con la plataforma Force.com, mi organización actual ha encontrado que varios enfoques diferentes pueden funcionar según la situación. Todos usamos el plugin Eclipse Force.com sin problemas y hemos encontrado que las siguientes configuraciones funcionan bien.

Tenemos un sistema de control de versiones centralizado que implementamos mediante el uso de una serie de comandos ant a una instancia de una organización de desarrolladores. Luego, dependiendo del alcance del trabajo, podemos separarlo en partes, ya que cada desarrollador tiene su propia organización de desarrollo y fusionar los cambios y probarlos con regularidad, o trabajar juntos en una sola organización de desarrollo (que si tiene 2 desarrolladores no debería problema importante) que le permite tener una integración casi instantánea.

Si ambos intentan trabajar en el mismo archivo, de todos modos debería estar programado en par, pero si trabajan juntos en dos componentes de un sistema similar, compartir la misma organización puede permitirle desarrollarse de manera rápida y flexible al crear el esqueleto de El sistema que desea utilizar y luego individualmente pulsa los detalles.

He utilizado ambos métodos ampliamente y, digo, funciona muy bien dependiendo de la situación.

Cada desarrollador podría trabajar en un entorno limitado de desarrollo separado (si tiene una edición para empresas, creo que ¿se incluyen 10 entornos limitados con configuración completa y cantidad limitada de datos en la tarifa?) . De vez en cuando usted fusionaría sus cambios (la herramienta de diferencias de cualquier sistema de control de versiones debería ser suficiente) y los probaría en un entorno de integración. La cadena de desarrollo-> integración-> prueba del sistema-> Q & A-> producción puede ser útil por otras razones también.

Se puede usar un truco separado para considerar si, por ejemplo, 2 individuos trabajan en el mismo disparador. Lo he aprendido en el curso "DEV 401" para desarrolladores.

  1. Mueve toda tu lógica a las clases. Seriamente. Serán más sencillos a prueba de unidad también.
  2. Agregue un campo personalizado (lista de selección múltiple) al objeto Usuario. Los valores deben ser iguales a cada característica por separado en la que están trabajando las personas. Puede contener hasta 500 valores por lo que debe estar seguro.
  3. Para la cuenta de usuario del desarrollador 1, configure "feature1" en la lista de selección. Establecer "feature2" para el otro chico.
  4. En el activador, escriba un if que comprueba la presencia de cada valor de lista de selección y entra o sale de la llamada a la clase relevante. Esto desperdicia 1 consulta pero está seguro de que solo se llamará el código que desea.
  5. Cada desarrollador sigue trabajando en su propio archivo de clase.
  6. Para la prueba de integración de ambas funciones, simplemente configure la selección múltiple para que contenga ambas funciones.

Encontré este truco especialmente útil cuando el código de otro chico resultó ser no óptimo y consumió demasiados recursos. Acabo de desactivar su función en mi cuenta de usuario y seguí trabajando.

Este truco también puede aplicarse en cierta medida a las páginas de Visualforce (si puede dividirlas en componentes).

Si no desea desperdiciar la consulta, use alguna lógica como "el nombre del usuario contiene X";)

Es posible que desee considerar trabajar en páginas y recursos estáticos separados y luego tener cuidado al editar objetos, clases, etc. Si la mayor parte de su desarrollo ocurre en el código del lado del cliente (página, recurso estático, componente / aplicación lightning), puede estar interesado en este proyecto: https://github.com/bvellacott/salesforce-build . En cualquier caso sugiero encarecidamente utilizar el control de versiones. Si no está en un servidor, al menos localmente en su máquina, en caso de que sus compañeros sobrescriban su trabajo.

No estoy familiarizado con force.com, pero no podría usar el control de código fuente y bajar todos los archivos desde force.com a su repositorio. Entonces todos podrían hacer su trabajo y fusionar sus cambios de nuevo en la línea principal. ¿Entonces cuando sea necesario empujar la línea principal hasta force.com?

Tuvimos / tenemos exactamente el mismo problema, tenemos un equipo de 10 Devs trabajando en una aplicación de force.com que tiene un montón de clases de vértice (> 300) y páginas VF (> 300).

Comenzamos a usar el plugin Eclipse pero lo encontramos:

  1. el trabajo es demasiado lento fuera de los EE. UU. cada vez que se llama guardar, se toman> 5 secciones
  2. a muchos problemas de fusión con un equipo de 10 desarrolladores

A continuación, intentamos desarrollar en nuestras propias cajas de arena individuales y luego fusionar el código. Esto está bien para un proyecto pequeño, pero cuando tiene muchos archivos y necesita que se introduzcan cambios entre los entornos limitados, resulta imposible gestionarlos, ya que lo único peor que tienen las herramientas de desarrollo de force.com es la herramienta de desarrollo / construcción de force.com. Sin automatización todo es manual. Tampoco es una forma fácil de mover datos entre los entornos limitados.

Nuestro tercer enfoque fue simplemente editar todas nuestras páginas de VF y el código de Apex en el navegador. (no utiliza su editor incrustado que se muestra en la mitad inferior de la página porque tiene errores y es lento), sino que solo usa el Editor regular en configuración> desarrollar> clases de Apex. Esto funcionó bien. Para complementar esto, también teníamos un trabajo programado que descargaría todo nuestro código y lo guardaría en nuestro repositorio SVN. También creamos una herramienta que nos permite hacer clic en una carpeta de nuestro escritorio, comprimir su contenido y desplegarlo como recursos estáticos para nosotros.

Sin embargo, este enfoque todavía tiene sus puntos cortos, es decir, su desarrollo en la nube es lento y doloroso, su idea (de fuerza de ventas) de Desarrollo como un Servicio es una locura. Además, no tenemos SCM real, solo lo tenemos actuando como copias de seguridad.

La conclusión es que force.com es un CRM y no una plataforma de desarrollo, si puede. corre, huye, aléjate de él tan rápido como puedas. Usarlo para cualquier cosa aparte de un CRM es más problema de lo que vale la pena. Incluso su eslogan "No Software" me hace reír cada vez.