Documentación para la versión en caja de Bitrix24. Completar el asistente de instalación

Marco Bitrix - Núcleo tecnológico (plataforma) para la creación y gestión de proyectos (sitios web y portales corporativos). La plataforma le permite crear una cantidad ilimitada de proyectos usando una copia (licencia) del producto, colocando el núcleo y la base de datos del sistema en una sola copia en el servidor.

En este momento no todas las funciones del kernel anterior están duplicadas en D7. Pero el nuevo núcleo D7 Marco Bitrix reemplaza gradualmente al antiguo. Si el uso del kernel anterior resultó en una advertencia del IDE: Method/class is obsoleto, entonces debe usar .

Por varias razones, es posible que la documentación de la API no cubra todos los métodos. Para comprender la operación, a veces es mejor mirar el código del programa real. Para esto puedes usar módulo gratuito del Mercado: .

Nota: al agregar #examples a la dirección de cualquier página, puede saltar rápidamente a un ejemplo si está en ella. (Esto no funciona en archivos de documentación con formato CHM).


Versiones de entidad

Marco Bitrix Constantemente evolucionando. Aparecen nuevas funciones, algunas quedan obsoletas, aparecen nuevos parámetros en las funciones. Sin embargo, una gran cantidad de proyectos no se actualizan. Para facilitar el trabajo del programador, la documentación indica de qué y para qué versión del producto existió (existe) la clase, método, parámetro, evento.

Las versiones se colocan en dos lugares: en el título y en las tablas. Si el método es válido, el título contendrá solo el número de versión con el que apareció en el producto. Si el método está desactualizado, allí se indicará el rango de versiones donde era válido.

Las tablas indican la versión con la que apareció la entidad en el producto, solo si su aparición no coincide con el momento de aparición de la propia clase, el método, etc. En la siguiente ilustración: el parámetro COURSE_ID apareció junto con el método (es decir, a partir de la 5.1.0), y el parámetro CAPÍTULO_ID solo a partir de la versión 9.5.4.

Si, con el desarrollo del producto, un parámetro (generalmente esto se refiere a parámetros) ha cambiado, habrá una nota correspondiente en su descripción. (Por ejemplo: antes de la versión x.x.x, el parámetro se llamaba *****).

Ejemplo

notas:

  • marca Obsoleto para un método, parámetro, clave significa que no se recomienda usarlo, ya que no habrá extensiones ni correcciones.
  • La instalación de versiones no se ha completado por completo, actualmente se está trabajando en esta dirección.

Bitrix, 2001-2019, 1C-Bitrix, 2019

La integración de una tienda en línea en 1C-Bitrix con el sistema se puede realizar utilizando el módulo del sistema en Bitrix.Marketplace.

Una vez instalado, el módulo ayudará a cargar los pedidos existentes en el sistema.

Una vez instalado, el módulo será:

  • cargar nuevos pedidos de 1C-Bitrix al sistema;
  • actualizar los datos de los pedidos existentes, teniendo en cuenta los cambios realizados en 1C-Bitrix;
  • cargar nuevos pedidos y clientes del sistema a 1C-Bitrix;
  • actualizar los datos de los pedidos existentes, teniendo en cuenta los cambios realizados en el sistema (por ejemplo, el estado del pedido, la cantidad de productos en el pedido, etc. han cambiado en el sistema; estos cambios también se reflejarán en 1C-Bitrix) );
  • enviar al sistema información sobre el pago en línea del pedido por parte del usuario.

También es posible personalizar clases de complementos sin perder el código modificado al actualizar. Para implementar el código modificado, debe colocar una copia del archivo con la clase requerida en el directorio bitrix/php_interface/retailcrm.

El complemento tiene la capacidad de personalizar los siguientes archivos:

RestNormalizer.php
registrador.php
Cliente.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.php
RetailCrmInventories.php
RetailCrmPrices.php
RetailCrmCollector.php
RetailCrmUa.php
RetailCrmEvent.php
RetailCrmHistory_v4.php
RetailCrmHistory_v5.php
RetailCrmOrder_v4.php
RetailCrmOrder_v5.php
ApiClient_v4.php
ApiClient_v5.php

Para personalizar los archivos cuyos nombres contienen la versión de la API utilizada, los archivos se crean con un nombre sin especificar la versión, por ejemplo, RetailCrmHistory.php.

Después de crear una copia del archivo con la clase en el directorio bitrix/php_interface/retailcrm, el módulo utilizará la clase personalizada, puede realizar cambios en sus métodos.

Dar de alta una tienda online en el sistema

Antes de la instalación, registre su tienda en línea en la instancia de su sistema (sección Administración > Tiendas, por ejemplo, en la versión de demostración):

Instalación de la solución en 1C-Bitrix

  • Haga clic en "Instalar" en la página de la solución en Marketplace e ingrese la dirección de su tienda en línea:

  • Descargue el módulo a través del Sistema de Actualización 1C-Bitrix:

  • Comience a instalar el módulo:

Se iniciará el asistente de instalación.

Asistente de instalación. Paso 1

En el paso 1.1, debe especificar la dirección de su sistema (por ejemplo, https://test.retailcrm.ru) y la clave API que generó anteriormente en el sistema:

¡Importante! Si solo hay una tienda en Bitrix, se omite el paso 1. Sitios.

Asistente de instalación. Paso 1. Sitios web

En el paso 1. Sitios, debe establecer una correspondencia entre sus tiendas en 1C-Bitrix y el sistema.

¡Importante! Todas sus tiendas en el sistema deben tener una clave API común.

Asistente de instalación. Paso 2

En el segundo paso, debe especificar la correspondencia entre los valores de la tienda en línea y los directorios del sistema. El módulo en sí trata de establecer una correspondencia para los estados típicos. Cuando el módulo no pudo hacerlo, debe especificar la coincidencia usted mismo:

Compruebe si el sistema tiene los valores de búsqueda necesarios correspondientes a las búsquedas de la tienda en línea. Si no son suficientes, agréguelos en la sección Administración sin cerrar la página del asistente de instalación:

Después de eso, actualice la página del asistente: se deben cargar los nuevos valores de referencia.

Asistente de instalación. Paso 3

En el tercer paso, el módulo le permite establecer la correspondencia entre los campos de 1C-Bitrix y el sistema.

¡Importante! Si hay un formulario comentario” o pedidos “en 1 clic”, y estos datos no se incluyen en los pedidos estándar de Bitrix, entonces no se introducen en el sistema.

Además, si está trabajando con entidades legales, debe completar todos los campos, como se indica en la captura de pantalla a continuación.

Asistente de instalación. Etapa 4

En el cuarto paso, el módulo le permite cargar los pedidos realizados previamente al sistema. La descarga puede tardar algún tiempo (1000 pedidos se descargan en unos 5 minutos). El progreso del proceso de descarga mostrará una barra de progreso.

Si es necesario, puede pausar la carga y reanudarla después de un tiempo.

Al cargar pedidos realizados anteriormente, podrá ver informes analíticos en el Panel KPI. Recomendamos hacer este paso.

Asistente de instalación. Paso 5

En el quinto paso se configura la descarga del catálogo de productos. Para hacer esto, siga los pasos a continuación.

1. Selección de infoblocks y propiedades

Los bloques de información seleccionados se cargarán en el sistema. Se le ofrecerá elegir solo aquellos bloques de información que contengan bienes o tengan bloques de información vinculados con ofertas comerciales. Paralelamente a la selección de bloques de información, puede seleccionar las siguientes propiedades: artículo, fabricante, color, peso, tamaño; para hacer esto, debe especificar la propiedad del bloque de información que se encarga de almacenar la propiedad correspondiente. Seleccionar una propiedad es opcional.

2. Ruta del archivo

Se generará un archivo en el formato en la ruta especificada, en el que se ubicará la estructura del directorio. La ruta predeterminada es - "/bitrix/catalog_export/retailcrm.xml". Si cambia la ruta, deberá realizar una configuración similar en el sistema.

3. Configuración del número de ofertas en la exportación

En la configuración de exportación del catálogo, hay un campo "Número máximo de ofertas comerciales por producto", donde debe ingresar el número máximo de ofertas comerciales que puede tener un producto (si hay más de 50). Por defecto, el módulo calcula un máximo de 50 ofertas comerciales para un producto. Si hay menos de 50 ofertas en la tienda para un producto, esta configuración se puede ignorar. Si hay más ofertas comerciales y se especifica la configuración, se recomienda transferir el agente a krones si funciona en hits.

4. Selección de la frecuencia de descarga

Habrá tres opciones a elegir:

1. No- cuando se selecciona este artículo, la descarga periódica del catálogo no se configurará automáticamente, y tendrá que descargar el catálogo cada vez.

Esta opción puede ser útil si el catálogo de productos de su tienda en línea cambia con muy poca frecuencia o si desea ajustar la configuración de carga más adelante.

2. cron- al seleccionar este elemento, se creará automáticamente un perfil especial que se vinculará al servicio Cron del servidor en el que opera el sitio web de la tienda en línea.

La utilidad cron se ejecuta en fondo y realiza las tareas especificadas en el momento especificado.

La elección de este artículo puede ser útil si el catálogo contiene una nomenclatura muy amplia ( más de 10.000 productos). Para este elemento, debe especificar el nombre del perfil de exportación personalizado.

3. Agente. En este caso, también se creará un perfil especial que se conectará a la tecnología "Agentes" en 1C-Bitrix, y se realizará la carga. automáticamente una vez al día.

Un agente es una función php que se ejecuta a cierta frecuencia. Al comienzo de la carga de cada página, el sistema verifica automáticamente si hay un agente que debe iniciarse y, si es necesario, lo ejecuta. No se recomienda crear agentes para cargas largas; es mejor usar cron.

Esta opción es más preferible si el directorio contiene menos de 10,000 artículos, entonces la carga es bastante rápida y esto no afectará la velocidad del sitio web de la tienda en línea.

En el caso de una gran nomenclatura ( más de 10.000 productos), se requiere una configuración adicional del Agente en Cron. Para este elemento, también debe especificar el nombre del perfil de exportación personalizado.

4. Indicación de descarga instantánea

Como resultado de configurar el indicador "Descargar ahora", la estructura del directorio se descargará en el archivo anterior, inmediatamente después de instalar el módulo.

Después de cargar el catálogo a un archivo en el sistema, vaya a Administración -> Tienda -> Nombre de la tienda -> pestaña Catálogo y marque la casilla "Descargar catálogo de ICML ahora". En este caso, la descarga del archivo y su procesamiento comienzan casi al instante.

5. Especificar un nombre de perfil

Después de configurar correctamente la carga del catálogo de productos, en la sección Tienda > Configuración > Exportación de datos, aparecerá un nuevo tipo de exportación del sistema, si especifica la carga periódica durante la instalación, también aparecerá un perfil de exportación.

Nota:
Para ajuste automático La descarga tiene la capacidad de crear su propio perfil de exportación.

Completar el asistente de instalación

Al final de la instalación, se crearán 2 agentes: un agente carga el historial de pedidos de Bitrix al sistema, el segundo agente genera un catálogo. Si la carga de pedidos está configurada para un agente, entonces los pedidos se cargan al sistema en el momento en que se llama al historial. En otros casos, las órdenes se descargan por evento.

Descarga del servicio de entrega durante el intercambio 1C-Bitrix - sistema

Si tiene servicios de entrega automatizados conectados a 1C-Bitrix, como eDost, que tienen muchos perfiles: Russian Post, EMS, DHL y muchos otros, entonces en el sistema puede aprovechar la capacidad de cargar este tipo de servicio de entrega.

Los métodos de entrega deben configurarse en el lado del sistema. Si el módulo del sistema se instaló antes de que el servicio de entrega se conectara a Bitrix, entonces los métodos de entrega faltantes deberán ingresarse en el sistema manualmente. Si el módulo se instaló después de conectar el servicio de entrega, los métodos de entrega se instalarán automáticamente, así como la descarga del servicio en sí. Es decir, para cada pedido, se descargará el coste del envío.

En el lado de 1C-Bitrix, se deben realizar las siguientes configuraciones si el módulo del sistema se instaló después de conectar el servicio de entrega al sistema 1C-Bitrix:

Ir a Administración > Configuración, vaya a la pestaña "Configuración de búsqueda".

Establecer la correspondencia de los métodos de entrega (previamente configurados del lado del sistema). A continuación, haga clic en el botón "Descargar servicios de entrega".

Configuración de la frecuencia de carga 1C-Bitrix - sistema

A la hora de actualizar el catálogo de productos se pueden distinguir dos puntos:

Generación de directorios (en formato yml/icml) en el lado del cliente y

El sistema descarga el catálogo cada tres horas. La ruta al archivo que se cargará se establece en la configuración de la tienda; debe ir a la sección Admin > Tiendas > Seleccionar tienda > Pestaña Catálogo.

Después de instalar el módulo del sistema en 1C-Bitrix, se crea un perfil para cargar. Para ver, debes ir a Escritorio > Tienda > Configuración > Exportación de datos. La captura de pantalla muestra dos opciones:

Por defecto,

Subiendo el directorio del sistema.

Si selecciona la segunda opción, al hacer clic en ella, puede abrir las opciones de carga.

Si se selecciona el Agente como la opción de periodicidad, para ver la lista de Agentes, debe ir a Escritorio > Configuración > Configuración del producto > Agentes.

Si hace clic en "Cambiar" o "Agregar nuevo", puede asignar o cambiar la frecuencia de inicio de la tarea para la generación.

La frecuencia de sincronización de datos durante el intercambio 1C-Bitrix - sistema

El módulo del sistema le permite cargar un catálogo de productos a su sistema, así como realizar un intercambio bidireccional regular de pedidos y clientes.

Con la descarga oportuna de datos del catálogo, los administradores de su sistema tendrán información actualizada sobre la disponibilidad de mercancías. La situación en la que se solicitan los productos y, después de un tiempo, resulta que están agotados, no se presentará.

El intercambio de pedidos es un proceso de sincronización de datos cuando los pedidos se cargan en ambas direcciones:

De 1C-Bitrix al sistema:

  • Si la descarga por eventos está habilitada, al crear o cambiar una orden en el sistema 1C-Bitrix, se descargará inmediatamente en el sistema. Si se selecciona un agente de descarga, la orden se descargará en el sistema dentro de los 15 minutos (no se recomienda utilizar este mecanismo sin buenas razones, ya que en este caso las órdenes llegan con retraso y las actualizaciones de estas órdenes no se transferirán a el sistema).
  • Al cambiar de usuario, los datos principales también se cargarán inmediatamente en el sistema.

Del sistema a 1C-Bitrix:

  • Si crea un pedido para un nuevo usuario en el sistema, el pedido se cargará en 1C-Bitrix y se creará un nuevo usuario en el intervalo de 1 a 15 minutos.
  • Si cambia la dirección, el costo de envío o el estado en el sistema en la página del pedido, todos estos cambios se cargarán en 1C-Bitrix en 15 minutos.
  • Si cambia los descuentos de bienes en el sistema y cambia la cantidad de bienes, esto también cambiará en 1C-Bitrix en el rango de 1 a 15 minutos.

Cambios en el módulo de integración

Versión 2.0

  • El módulo de integración V2.0 está diseñado para integrar 1C-Bitrix con la versión del módulo "Tienda en línea (venta)"> 16 instalada en él.
  • Ahora el trabajo del módulo se realiza a través de la API V4.
  • El módulo de integración ahora usa el nuevo núcleo 1C-Bitrix D7.
  • Ahora desde el sistema, el sitio también recibe cambios para el cliente (nombre completo, correo electrónico, teléfono).
  • En la configuración del módulo de integración en la sección "Otras configuraciones", fue posible transmitir números de pedido del sistema a 1C-Bitrix. Es decir, si se crea manualmente en el sistema un pedido con un número, por ejemplo, 12345R, se creará un pedido con el mismo número en 1C-Bitrix.
  • Dado que en el módulo "Tienda en línea (venta)" versión > 16, los desarrolladores de Bitrix dejaron la aplicación de descuentos a todo el pedido y dejaron descuentos solo para bienes, el sistema, hasta el momento, tampoco tiene la capacidad de usar descuentos para todo el pedido. Puede establecer descuentos solo para artículos de pedido específicos.

Versión 2.1

  • Se agregaron unidades de medida en la exportación del catálogo.

Versión 2.2

  • El módulo ahora admite múltiples versiones de API con una opción.
  • Compatibilidad con API V5.
  • Se agregó la capacidad de descargar residuos en el contexto de los almacenes.
  • Se agregó la capacidad de descargar tipos de precios.
  • Se agregó la integración básica de Daemon Collector.
  • Se agregó integración con Universal Analytics.
  • Se ha mejorado la lógica de las funciones integradas para la modificación de datos.
  • Se agregó la función retailCrmApiResult incorporada.
  • Se agregó una versión de activación del historial de cambios.

Versión 2.4

  • Se agregó un cheque en el controlador para guardar el pago de un nuevo pedido.
  • Configuración agregada para el número de ofertas comerciales en la exportación.
  • Se agregó la conversión del precio de compra.
  • Cambio de archivos de traducción.
  • Se agregó verificación en la descarga de cambios del sistema para las propiedades del pedido.
  • Subida de IVA añadida.
  • Se corrigió la obtención de una lista de tipos de precios para la descarga. Todos los tipos disponibles en Bitrix están disponibles para su selección.

Otros ajustes

Configuración de pedidos

Transmita los números de pedidos creados en el CRM a la tienda

Al crear un pedido en el sistema, tiene su propio número único de acuerdo con las reglas especificadas. Cuando esta configuración se establece en el módulo, el número de dicho pedido se transferirá a la tienda durante la sincronización inversa.

Descarga de pedidos

  • por evento- al grabar el pedido, los datos entran en el sistema;
  • agente- Los nuevos pedidos se envían antes de solicitar el historial de cambios del sistema.

Versión de la API del cliente

Ahora puede elegir la versión de la API con la que funcionará el módulo. La elección depende de la versión del sistema. Se recomienda elegir la última versión.

Habilitar descarga de saldos en el contexto de almacenes (disponible si hay almacenes)

Ahora puede descargar periódicamente los residuos de los almacenes del sitio a los almacenes del sistema. Para esto necesitas:

  • comparar los almacenes del sitio con los almacenes del sistema;
  • especificar las tiendas del sistema en las que se cargarán los saldos;
  • seleccione los bloques de información con los bienes necesarios para cargar las sobras (debe seleccionar los que se especifican en la exportación del catálogo para el sistema).

La descarga la realiza el agente con una frecuencia de 1 hora (por defecto).

Tenga en cuenta que para cargar las sobras en el sistema, las opciones deben estar habilitadas.

Habilite la carga de tipos de precios para productos (solo disponible si hay varios tipos de precios)

Ahora puede cargar periódicamente tipos adicionales de precios de la tienda al sistema. Para esto necesitas:

  • comparar los tipos de precios del sitio con los tipos de precios del sistema;
  • especifique las tiendas del sistema en las que se cargarán tipos adicionales de precios;
  • seleccione bloques de información con productos que requieran cargar tipos de precios adicionales (debe seleccionar aquellos que se especifican en la exportación del catálogo para el sistema).

La descarga la realiza el agente con una frecuencia de 24 horas (por defecto).

Activar el recopilador de demonios

Ahora puede agregar un Collector Daemon a su sitio desde la interfaz de configuración. Para hacer esto, debe especificar la clave apropiada para el sitio deseado. La clave se puede encontrar en el sistema.

Habilitar la integración de UA

Ahora puede habilitar la integración con Universal Analytics desde la interfaz de configuración (funciona correctamente con el componente de pago estándar). Para cada sitio al que desee agregar seguimiento, deberá completar un ID de seguimiento y un índice de dimensión personalizado.

Donde $order es una matriz de datos de pedidos que se enviarán al sistema y $arFields es una matriz de campos de pedidos en el sitio. función retailCrmBeforeOrderSave($pedido) (//Sus cambios devuelven $pedido; //o devuelven falso; y luego se ignorarán los cambios del sistema para este pedido)

Donde $pedido es una matriz con datos de pedidos modificados que provienen del sistema.

función retailCrmAfterOrderSave

retailCrmAfterOrderSave: una función que se ejecuta inmediatamente después de guardar en el sitio los cambios en los datos del pedido que provienen del historial del sistema.

function retailCrmAfterOrderSave($order) ( //Tus cambios regresan; )

Donde $pedido es una matriz con datos de pedidos modificados provenientes del sistema.

función retailCrmApiResult

retailCrmApiResult: una función que se ejecuta inmediatamente después de recibir una respuesta de la API del sistema.

function retailCrmApiResult($methodApi, $res, $code) ( //Tus cambios regresan; )

Donde $methodApi es el nombre del método API, $res es el resultado de la solicitud verdadera/falsa (solicitud exitosa o fallida), $code es el código de estado de la respuesta API.

Tenga en cuenta que los errores en el código al usar esta función pueden interrumpir la sincronización del sitio y el sistema.

Si las herramientas enumeradas anteriormente no son suficientes por algún motivo, puede realizar los cambios necesarios directamente en el código del módulo sin correr el riesgo de perder estos cambios al actualizar el módulo. Para hacer esto, debe copiar el archivo con la clase requerida en el directorio /bitrix/php_interface/retailcrm/ y modificarlo ya en él. Este mecanismo soporta cambio de clases para trabajar con clientes, pedidos, eventos, exportación de catálogo y otros mecanismos auxiliares.


Marcador Tareas personalizadas está destinado a quienes trabajarán directamente con el producto, es decir, a los empleados de las empresas que utilizan nuestro producto de software.

La pestaña Tareas del administrador está destinada a aquellos que administrarán la versión en caja Bitrix24.

Marcador Documentación diseñado para desarrolladores de proyectos basados ​​en la versión en caja Bitrix24.

Tareas personalizadas

Tareas del administrador

Desarrolladores

La documentación del desarrollador es una descripción de la API del sistema. La documentación del usuario es una descripción de los componentes y la configuración del sistema.

La documentación está disponible tanto en línea como en un archivo chm. Se recomienda utilizar la versión en línea ya que está más actualizada. Los archivos chm se actualizan periódicamente y es posible que no contengan información sobre las últimas versiones.

¡Atención! Si no ve el contenido del archivo de formato .chm, entonces la razón es la configuración de seguridad Sistema operativo. En las propiedades del archivo, debe eliminar el bloqueo de visualización del archivo. Leer más enPREGUNTAS MÁS FRECUENTES.

La documentación es información de referencia. No es suficiente que un desarrollador novato trabaje con el sistema. Al dominar los principios de la programación en Marco Bitrix un curso especial te ayudará a:

No hace mucho tiempo, nuestra empresa recibió una tienda en línea bastante grande en 1C-Bitrix para mantenimiento y revisión. El proyecto se puso en operación comercial durante un par de meses, pero al mismo tiempo tenía una serie de problemas graves. Además, el cliente planeó completar las tareas de finalización de la nueva funcionalidad lo antes posible. Me dieron la tarea de organizar trabajo eficiente proyecto con un tiempo de inactividad mínimo del sitio y la máxima satisfacción del cliente.

Datos iniciales:

  • Hay una tienda en línea en 1C-Bitrix
  • El proyecto tiene varios años, pero hace solo unos meses el sitio fue transferido a 1C-Bitrix
  • Asistencia 10-15 mil personas por día
  • El catálogo de la tienda contiene alrededor de 12,000 artículos de bienes.
  • El tiempo de inactividad y las interrupciones del sitio son inaceptables
  • El proyecto fue desarrollado por otra empresa durante seis meses:
    1. Hay un TOR, unas 100 hojas, correspondiente al trabajo realizado por alrededor del 40%
    2. Sin documentación del proyecto
    3. Falta de comprensión de por qué los desarrolladores anteriores usaron tales soluciones arquitectónicas.

Desarrollo software en general, y proyectos web en particular, llevo haciendo unos 8 años. Durante este tiempo, me enfrenté a proyectos de diversa complejidad y, a primera vista, la tarea no me pareció demasiado difícil. Al implementar proyectos en nuestra empresa, por regla general, se utiliza la metodología SCRUM. Empecé a alejarme de ella.

En primer lugar, obtuve acceso código fuente proyecto. Superficialmente analizado. Acordado con el cliente una lista de tareas prioritarias. Hice un plan de desarrollo para 3 desarrolladores y, como dijo Gagarin, ¡vamos!

Problema número 1: los desarrolladores tienen la culpa

Como suele ocurrir, todo el mundo tiene la culpa de todo menos el cliente. El diseñador hizo un diseño que pesa demasiado, el host proporcionó un servidor que es lento, los desarrolladores crearon un sitio que tiene errores y se rompe todo el tiempo, los administradores completaron algunas tareas que no solicitamos realizar después de cambiar de versión antigua sitio en 1C-Bitrix, hubo una fuerte disminución en el tráfico de búsqueda, etc. La situación no está clara. Por un lado, la responsabilidad principal, por supuesto, debe recaer en la empresa desarrolladora. Era necesario transmitir al cliente las consecuencias de todas las acciones con el sitio y prepararse para el resultado. Al realizar el trabajo, ofrecer una arquitectura holística sistema futuro y un plan de desarrollo a seguir hasta que se completen los hitos. Realice una prueba exhaustiva de la funcionalidad y entregue el trabajo. Por otro lado, a menudo me encuentro con una situación en la que el cliente sabe todo mejor por sí mismo, porque su madre una vez pintó, y por lo tanto es mejor diseñador, y su hijo de 7 años está bien versado en SEO porque pasa todo su tiempo en la computadora jugando GTA.

Quién tiene la culpa, quién tiene la razón, no nos corresponde a nosotros juzgar. En este caso, el contratista anterior era una empresa confiable bastante conocida y no puedo decir nada malo sobre su desarrollo. Y el cliente, objetivamente, se preocupa por su producto y trata de mejorarlo. No sé cómo fue, yo mismo encontré una explicación en la cantidad insuficiente de análisis proporcionados por el contratista al cliente.

Como resultado:

  • El proyecto no ha llegado a su conclusión lógica. Muchas tareas se abandonan a mitad del camino
  • El proyecto no está documentado. El trabajo de una parte de la funcionalidad no es obvio. Al desarrollar una nueva funcionalidad, resulta que la funcionalidad que antes funcionaba y cuya existencia el nuevo desarrollador no sospechaba dejó de funcionar.
  • Parte del código escrito por el ejecutor anterior tiene que ser reescrito desde cero
  • La arquitectura prevista del proyecto en las primeras semanas/meses de trabajo no está clara para el nuevo contratista. El refinamiento de la funcionalidad de un módulo conduce a la pérdida de funcionalidad de la funcionalidad de un módulo que no está relacionado con él de ninguna manera.
  • El cliente está nervioso, el artista está nervioso, los visitantes no están contentos, la asistencia está disminuyendo, las ventas están cayendo

Solo veo una solución al problema: limpiar gradualmente y sistemáticamente todos los módulos del sitio para llevar el producto al estado requerido. Algunos errores se movieron a tareas separadas y se ejecutaron de inmediato, algo se corrigió en paralelo con el desarrollo de la nueva funcionalidad. El resultado: con cada actualización, después de la limpieza operativa de los errores que han aparecido, el sitio se vuelve mejor y más estable.

El problema #2 es el desarrollo paralelo.

De acuerdo con la política de licencias de 1C-Bitrix, cada licencia de sitio le permite utilizar 2 copias del sistema. Uno como sitio de producción, el segundo - para el desarrollo. El problema es que el desarrollo lo realizan varios, en mi caso tres, desarrolladores continuamente. En el caso del desarrollo clásico, todo es simple. Cada desarrollador trabaja en su propio módulo. Luego se lleva a cabo la prueba funcional de cada módulo, todas las mejoras se fusionan en el repositorio de algún sistema de control de versiones, luego se prueba todo junto (prueba de integración). Si el resultado es normal, se presenta la versión de prueba al cliente. Una vez que se acepta la versión de prueba, se actualiza el servidor de producción. De acuerdo con la metodología SCRUM, he determinado que subiré nuevas versiones al sitio de producción una vez por semana. En consecuencia, hay 3-4 días para el desarrollo principal. 1 día para probar y corregir errores y medio día para actualizar el servidor de combate. Por supuesto, los plazos fluctúan, pero traté de cumplir estrictamente con la regla de "publicación todos los jueves".

Lo primero que encontré fue que en 1C-Bitrix hay situaciones en las que el mismo archivo está simultáneamente involucrado en diferentes funciones en diferentes extremos del sitio. La solución más sencilla y obvia es utilizar un sistema de control de versiones, en mi caso, SVN, que utilizo en todos los demás proyectos. Pero para usar el control de versiones, es necesario que cada desarrollador tenga su propia versión del código, que edita y luego fusiona el repositorio común.

¿Qué pasa con la licencia? Me puse en contacto con el soporte técnico de 1C-Bitrix. Recibió una oferta para comprar más. licencias de desarrollo. Para decirlo suavemente, no estaba contento, pero no recibí ninguna otra oferta. Encontré una salida bastante rápido. Decidió usar claves NFR. Afortunadamente, el estado de socio lo permite. Como resultado, creé 5 instalaciones de la tienda en línea:

  • Servidor de producción
  • servidor de prueba
  • 3 servidores de desarrollo (uno por desarrollador)

Con el tiempo, fue aún más lejos. También había una instalación separada para el probador. Resultó que con mi suerte, el cliente siempre ingresa al servidor de prueba en el momento en que algo se está actualizando allí. En el bugtrack, hay muchas tareas innecesarias que ya se han completado, y el cliente tiene la impresión de que no estamos haciendo bien nuestro trabajo.

Actualmente estoy usando el siguiente esquema:

  • Cada desarrollador usa solo su copia local para el trabajo
  • En el momento acordado, todas las mejoras completadas se fusionan en una rama común en el repositorio
  • QA recoge una versión "manchada" para probar
  • Después de probar y corregir errores, el servidor de demostración se actualiza para el cliente
  • Después de la verificación y aceptación por parte del cliente, las mejoras se transfieren al servidor de combate.

De las desventajas obvias de este enfoque, quiero resaltar el bajo nivel de participación del cliente en el desarrollo. El resultado es visible para el cliente solo en la etapa final. Este enfoque es aplicable si tiene un buen analista que rara vez comete errores y está en contacto constante con el cliente. De lo contrario, habrá que rehacer muchas tareas desde cero.

Mientras construía el circuito, me encontré con otro problema. El proyecto ocupa unos 80 GB en el disco. Sin caché y archivos temporales: alrededor de 60. Al principio, intenté eliminar imágenes y videos del control de versiones, pero no funcionó. La información en el sitio cambia constantemente. Necesita probar con los datos actuales. La primera confirmación del sitio en el repositorio se hizo pedazos durante más de 2 días. El primer pago a la carpeta de desarrollo lleva varias horas (servidor SVN en red local desarrollo). Si, Dios no lo quiera, accidentalmente realiza una actualización completa de la carpeta del proyecto, puede ir a fumar, cenar, jugar al ping-pong o al curling. Confirmar solo archivos o carpetas seleccionados es lo suficientemente rápido. Solución: completó la tarea: confirmar una docena de archivos modificados a la vez.

Problema n.º 3: actualizar el servidor de producción y colaborar con el cliente

El problema es el más importante, complejo y, al final, no resuelto. Después de todo, si el resto de los problemas se relacionan con la cocina interna del proyecto, entonces la reputación y los ingresos del cliente y, en consecuencia, mis ingresos dependen del trabajo del sitio.

Aquí es donde entran en juego las leyes de Murphy:

  • Si algo no funciona bien en un servidor de prueba, definitivamente fallará en un servidor de producción.
  • Si algo funciona bien en un servidor de prueba, definitivamente fallará en un servidor de producción de todos modos.
  • Si existe un error en el sitio durante solo 5 segundos, uno de los visitantes definitivamente lo encontrará y escribirá sobre él en las reseñas o en el formulario de comentarios.
  • Si el sitio no funciona durante 1 minuto durante la actualización, es en ese momento que el propietario de la empresa se lo mostrará a su amigo o competidor (y esto a pesar de la coordinación del tiempo y el procedimiento para la actualización).
Por supuesto, estoy exagerando, pero en cada broma hay una parte de una broma. La carga mínima en el sitio es de 4 a 6 de la mañana. Por supuesto, sería mejor actualizar en este momento, pero realmente no quiero hacerlo.

En el caso de la mayoría de las aplicaciones web, existe una estructura clara para dividir la aplicación en capas y actualizar el sitio se puede dividir en 2 partes:

  • Actualización de código
  • Actualización de la base de datos mediante scripts SQL

En el caso de 1C-Bitrix, todo es un poco más complicado. Primero, hay muchos archivos. Tengo más de un millón de ellos en mi proyecto. La actualización habitual desde el repositorio tarda no menos de 20-30 minutos. Por supuesto, solo puede actualizar los archivos modificados, pero luego se pierde todo el sentido del repositorio. En segundo lugar, y esto es mucho más triste, a menudo, al actualizar, debe realizar cambios y configuraciones manuales a través del panel de administración. Y esto siempre es lento, debe recordar todos los cambios que deben realizarse, existe una alta probabilidad de cometer un error accidentalmente. Por supuesto, puede escribir un script SQL que realice todos los cambios necesarios en la base de datos. En los casos más simples, por supuesto, hacemos precisamente eso. Pero en la mayoría de los casos, escribir y depurar un script de este tipo lleva más tiempo que el desarrollo en sí y mucho más tiempo que hacer todas las acciones manualmente con la verificación posterior.

Todavía no he encontrado una buena solución. Ahora actualizamos la configuración en la base de datos manualmente. Para minimizar los errores, se compila una lista de verificación con una lista de lo que se debe hacer durante la actualización. Tratamos de actualizar con el mayor cuidado y precisión posible. Después de la actualización, todo el equipo verifica la funcionalidad principal del servidor de producción y realiza pruebas adicionales. Se ha minimizado la cantidad de errores, pero los errores y el tiempo de inactividad durante las actualizaciones aún no se han eliminado por completo.

La segunda cosa que encontré es trabajo en equipo Con el cliente. Porque el proyecto es grande, alrededor de 30 personas están trabajando constantemente en él. Administradores de contenido, gerentes de ventas, optimizadores de SEO, especialistas en marketing y muchos más. Naturalmente, todos realizan algunos cambios en las páginas del sitio y la configuración de los módulos. La primera decisión fue quitarle al cliente los derechos de realizar cambios en el código del programa del sitio. La decisión es absolutamente correcta, pero solo empeoró. Si antes el cliente suponía que también podía ir al sitio y romper algo accidentalmente, ahora todos los golpes comenzaron a caer solo sobre nosotros. ¿En qué? Incluso si el administrador de contenido editó torcidamente el texto de la página y no cerró alguna etiqueta, el desarrollador sigue siendo el culpable. La solución resultó ser bastante simple. El mercado tiene un módulo de control de versión de página gratuito. Esto no eliminó el problema, de todos modos, alguien de vez en cuando hará algo, pero ahora es posible ver en cualquier momento quién cambió, qué cambió y por qué todo se rompió. El resultado, por supuesto, no es hielo, pero me ahorra muchos nervios.

Además, tomamos una decisión antes de cada actualización del servidor de prueba, le llevamos una copia del servidor de producción. Esto también lleva mucho tiempo. Archive el proyecto, muévalo a otro servidor, descomprímalo. Todo esto lleva varias horas. Pero, las nuevas mejoras se prueban casi en condiciones de combate. Si las configuraciones de los servidores de prueba y producción son idénticas, la diferencia en la operación será mínima y la cantidad de errores se reducirá significativamente. Como ha demostrado la experiencia, un servidor de producción puede cambiar tanto en una semana que algunas de las nuevas funciones que funcionan sin problemas en una copia de hace una semana pueden no funcionar en absoluto en una copia nueva.

Problema número 4 - "hazme urgente, esta es una tarea de 5 minutos"

El problema no se relaciona tanto con 1C-Bitrix, sino con el refinamiento y el soporte de proyectos existentes. A menudo, el cliente tiene el deseo de hacer algo pequeño, pero de manera urgente e inmediata en el sitio de combate. El resultado es siempre el mismo: no sale nada bueno. En el mejor de los casos, esta mejora simplemente se olvidará durante la próxima versión, en el peor de los casos, el servidor simplemente se caerá y llevará varias horas restaurarlo desde la copia de seguridad.

Solo encontré una solución: nunca seguir el ejemplo del cliente en detrimento de la confiabilidad y la seguridad. No importa cómo pregunte el cliente, el desarrollador siempre tendrá la culpa. Como me dijo mi exjefe: “Yo no te pedí que hicieras cosas malas”.

Y ya que tocamos el tema de las copias de seguridad, quiero señalar. La copia de seguridad con 1C-Bitrik es ciertamente buena y conveniente, pero muy lenta. Si necesita restaurar urgentemente 1-2 archivos o varios valores en la base de datos, debe esperar hasta que se descompriman los 60 GB. Aquí el siguiente esquema me parece el más efectivo:

  • Debe haber una copia de seguridad diaria de los archivos y la base de datos en forma de archivo en fuente externa datos.
  • Siempre hacemos una copia de seguridad inmediatamente antes de actualizar en una de las 2 opciones:
    1. Luz de opción: copie toda la carpeta del proyecto en una carpeta adyacente en el servidor. La base de datos en forma de volcado se guarda en un archivo separado. No archivamos nada. En caso de que necesite restaurar algún valor en la base de datos o en uno de los archivos, todo estará a la mano y de fácil acceso.
    2. La opción fuerte es similar a la anterior, solo que copiamos la base a otra base datos mysql. Esto permitirá, en el caso de un bloqueo completo en 1-2 minutos, reparar la carpeta raíz del sitio en el archivo de hosts y el proyecto comenzará a funcionar desde la carpeta vecina con una copia de la base de datos.

Conclusión

Gracias a todos los que leyeron hasta el final. Espero que mi experiencia te sea útil. Estaré encantado de recibir sugerencias sobre formas más exitosas de resolver los problemas expresados ​​​​en los comentarios o en un contacto personal. Ahora he tratado de expresar los principales problemas de refinación y soporte de proyectos ya lanzados con requisitos de alta confiabilidad. Si el material resulta interesante, planeo escribir una continuación sobre las características de la arquitectura 1C-Bitrix que distinguen el desarrollo de un sitio en Bitrix del desarrollo de otros proyectos web.

Información sobre cómo trabajar con se puede encontrar en tutoriales y documentación. Los cursos de formación están diseñados para dominar los métodos de trabajo en producto de software y documentación - para dominar los principios de la personalización de CMS.

al trabajar con "1C-Bitrix: Administración del sitio" los problemas surgen en forma de problemas prácticos específicos. Hemos recopilado varias páginas de cursos de capacitación en temas de perfil para que le resulte más fácil encontrar respuestas a sus preguntas.



Centros de formación Hacer una pregunta Foro



Marcador Administradores de contenido está destinado a quienes trabajarán directamente con el producto, es decir, a los administradores de contenido que lideran proyectos creados en nuestro producto de software.

Marcador Administradores destinado a quienes van a administrar "1C-Bitrix: Administración del sitio".

Marcador Desarrolladores diseñado para desarrolladores de proyectos basados ​​en "1C-Bitrix: Administración del sitio".

Administradores de contenido

Puedes importar el curso a tu sitio Gestor de contenidos de este archivo. Curso sin preguntas para exámenes.
Versión del curso fechada el 05/06/2015.

Administradores

Desarrolladores

La documentación del desarrollador es una descripción de la API del sistema. La documentación del usuario es una descripción de los componentes y la configuración del sistema.

La documentación está disponible tanto en línea como en un archivo chm. Se recomienda utilizar la versión en línea ya que está más actualizada. Los archivos chm se actualizan periódicamente y es posible que falte información sobre Últimos cambios en el sistema de ayuda.

¡Atención! Si no ve el contenido del archivo de formato .chm, entonces el motivo es la configuración de seguridad del sistema operativo. En las propiedades del archivo, debe eliminar el bloqueo de visualización del archivo. Leer más enPREGUNTAS MÁS FRECUENTES.

La documentación es información de referencia. No es suficiente que un desarrollador novato trabaje con el sistema. Al dominar los principios de la programación en Marco Bitrix un curso especial te ayudará a:


Arriba