› › Dokumentation för den förpackade versionen av Bitrix24. Slutför installationsguiden

Dokumentation för den förpackade versionen av Bitrix24. Slutför installationsguiden

Bitrix ramverk - teknisk kärna (plattform) för att skapa och hantera projekt (webbplatser och företagsportaler). Plattformen låter dig skapa ett obegränsat antal projekt med en kopia (licens) av produkten, placera kärnan och databasen i systemet i en enda kopia på servern.

På det här ögonblicket inte alla funktioner i den gamla kärnan dupliceras i D7. Men den nya D7-kärnan Bitrix ramverk gradvis ersätta den gamla. Om användning av en gammal kärna resulterade i en varning från IDE: Metod/klass är utfasad måste du använda metoder.

Av flera skäl kanske inte API-dokumentationen täcker alla metoder. För att förstå hur det fungerar är det ibland bättre att titta på själva programkoden. För detta kan du använda gratis modul från Marketplace: .

Notera: genom att lägga till #exempel till adressen till vilken sida som helst kan du snabbt gå till ett exempel, om det har ett. (Detta fungerar inte i dokumentationsfiler i CHM-format.)


Entitetsversioner

Bitrix ramverk utvecklas ständigt. Nya funktioner dyker upp, vissa blir föråldrade och nya parametrar dyker upp i funktioner. Ett ganska stort antal projekt uppdateras dock inte. För att underlätta programmeringsarbetet anger dokumentationen med vilken version av produkten klassen, metoden, parametern, händelsen existerade (existerar).

Versioner listas på två ställen: i titeln och i tabellerna. Om metoden är giltig kommer titeln endast att innehålla versionsnumret som den förekom i produkten. Om metoden är föråldrad, kommer även intervallet av versioner där den var giltig att anges.

Tabellerna anger versionen med vilken enheten dök upp i produkten endast om dess utseende inte överensstämmer med ögonblicket för klassens utseende, själva metoden och så vidare. I illustrationen nedan: parametern COURSE_ID dök upp tillsammans med metoden (det vill säga från 5.1.0), och parametern CHAPTER_ID endast från version 9.5.4.

Om en parameter (vanligtvis hänvisar detta till parametrar) har ändrats med utvecklingen av produkten, kommer det att finnas en motsvarande notering i dess beskrivning. (Till exempel: före version x.x.x kallades parametern *****).

Exempel

Anteckningar:

  • Mark Föråldrad för en metod, parameter eller nyckel betyder att det inte rekommenderas att använda den eftersom det inte kommer att finnas några tillägg eller korrigeringar.
  • Installationen av versioner har inte slutförts helt, arbete i denna riktning pågår för närvarande.

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

Integrering av en webbutik på 1C-Bitrix med systemet kan göras med hjälp av systemmodulen i Bitrix.Marketplace.

Under installationen hjälper modulen dig att ladda upp befintliga beställningar till systemet.

Efter installationen kommer modulen:

  • ladda upp nya beställningar från 1C-Bitrix till systemet;
  • uppdatera data om befintliga beställningar med hänsyn till ändringar gjorda i 1C-Bitrix;
  • ladda upp nya beställningar och klienter från systemet till 1C-Bitrix;
  • uppdatera data om befintliga beställningar med hänsyn till ändringar som gjorts i systemet (till exempel ändrades beställningens status i systemet, antalet varor i beställningen etc., dessa ändringar kommer också att återspeglas i 1C-Bitrix) ;
  • skicka information om onlinebetalning av en beställning av användaren till systemet.

Det är också möjligt att anpassa plugin-klasser utan att förlora den modifierade koden vid uppdatering. För att implementera den modifierade koden måste du placera en kopia av filen med den obligatoriska klassen i katalogen bitrix/php_interface/retailcrm.

Insticksprogrammet har möjlighet att anpassa följande filer:

RestNormalizer.php
Logger.php
Client.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

För att anpassa filer vars namn inkluderar API-versionen som används skapas filer med ett namn utan att specificera versionen, till exempel - RetailCrmHistory.php.

Efter att ha skapat en kopia av filen med klassen i katalogen bitrix/php_interface/retailcrm kommer modulen att använda en anpassad klass; du kan göra ändringar i dess metoder.

Registrering av en webbutik i systemet

Före installationen, registrera din webbutik i din instans av systemet (avsnittet Administration > Butiker, till exempel i demoversionen):

Installera lösningen i 1C-Bitrix

  • Klicka på "Installera" på lösningssidan på Marketplace och ange adressen till din webbutik:

  • Ladda ner modulen via 1C-Bitrix Update System:

  • Börja installera modulen:

Installationsguiden startar.

Installationsguide. Steg 1

I steg 1.1 måste du ange adressen till ditt system (till exempel https://test.retailcrm.ru) och API-nyckeln som du genererade tidigare i systemet:

Viktig! Om det bara finns en butik i Bitrix, steg 1. Webbplatser hoppas över.

Installationsguide. Steg 1. Webbplatser

I steg 1.Sites måste du ställa in korrespondensen mellan dina butiker i 1C-Bitrix och systemet.

Viktig! Alla dina butiker i systemet måste ha en gemensam API-nyckel.

Installationsguide. Steg 2

I det andra steget måste du ange överensstämmelsen mellan värdena för onlinebutiken och systemkatalogerna. Modulen själv försöker upprätta korrespondens för typiska statusar. Om modulen misslyckades med detta måste du ange matchningen själv:

Kontrollera om systemet har de nödvändiga katalogvärdena som motsvarar onlinebutikskatalogerna. Om det inte finns tillräckligt med dem, lägg till dem i avsnittet Administration utan att stänga sidan med installationsguiden:

Uppdatera sedan guidesidan: de nya katalogvärdena ska laddas.

Installationsguide. Steg 3

I det tredje steget låter modulen dig ställa in överensstämmelsen mellan fälten i 1C-Bitrix och systemet.

Viktig! Om det finns ett formulär " respons"eller beställningar "i 1 klick", och denna data faller inte in i standard Bitrix-order, då dras de inte in i systemet.

Även om du arbetar med juridiska personer, måste du fylla i alla fält enligt skärmdumpen nedan.

Installationsguide. Steg 4

I det fjärde steget låter modulen dig ladda upp tidigare gjorda beställningar i systemet. Avlastningen kan ta lite tid (1000 beställningar lossas på cirka 5 minuter). Uppladdningsprocessens förlopp kommer att visas av en förloppsindikator.

Om det behövs kan du pausa nedladdningen och återuppta efter ett tag.

Efter att ha laddat upp tidigare gjorda beställningar kommer du att kunna se analytiska rapporter i KPI-panelen. Vi rekommenderar att du utför detta steg.

Installationsguide. Steg 5

I det femte steget konfigureras uppladdning av produktkatalogen. För att göra detta måste du slutföra följande punkter.

1. Val av informationsblock och egenskaper

De valda informationsblocken kommer att laddas upp till systemet. Du kommer att erbjudas ett val endast av de informationsblock som innehåller produkter eller har länkade informationsblock med handelserbjudanden. Parallellt med valet av informationsblock kan du välja följande egenskaper: artikel, tillverkare, färg, vikt, storlek - för detta måste du ange informationsblockegenskapen, som ansvarar för att lagra motsvarande egenskap. Att välja en egenskap är valfritt.

2. Filsökväg

En fil i formatet kommer att genereras på den angivna sökvägen, som kommer att innehålla katalogstrukturen. Standardsökvägen är - "/bitrix/catalog_export/retailcrm.xml". Om du ändrar sökvägen måste du utföra en liknande inställning i systemet.

3. Ställa in antalet erbjudanden i export

I katalogexportinställningarna finns ett fält "Maximalt antal erbjudanden för en produkt", där du måste ange det maximala antalet erbjudanden som en produkt kan ha (om det finns fler än 50). Som standard beräknar modulen maximalt 50 erbjudanden för en produkt. Om det finns mindre än 50 erbjudanden per produkt i butiken kan denna inställning ignoreras. Om det finns fler handelserbjudanden och inställningen är specificerad, rekommenderas att överföra agenten till kronor om det fungerar på träffar.

4. Välja avlastningsfrekvens

Det kommer att finnas tre alternativ att välja mellan:

1. Nej- när du väljer detta objekt kommer periodisk uppladdning av katalogen inte att konfigureras automatiskt, och du måste ladda upp katalogen själv varje gång.

Det här alternativet kan vara användbart om produktkatalogen för din webbutik ändras mycket sällan, eller om du vill konfigurera uppladdningsparametrarna senare.

2. Cron- att välja detta objekt kommer att leda till att en speciell profil skapas automatiskt som kommer att länkas till Cron-tjänsten på servern som webbutikens webbplats fungerar på.

Cron-verktyget körs in bakgrund och utför specificerade uppgifter vid angivna tider.

Att välja det här objektet kan vara användbart om katalogen innehåller ett mycket stort objekt ( mer än 10 000 produkter). För denna artikel måste du ange namnet på den speciella exportprofilen.

3. Ombud. I det här fallet kommer också en speciell profil att skapas som kommer att ansluta till "Agents" -tekniken i 1C-Bitrix, och uppladdningen kommer att ske automatiskt en gång om dagen.

En agent är en PHP-funktion som körs med en viss frekvens. I början av varje sidladdning kontrollerar systemet automatiskt om det finns en agent som måste startas och kör den vid behov. Det rekommenderas inte att skapa agenter för tidskrävande uppladdningar - det är bättre att använda cron.

Det här alternativet är mest att föredra om katalogen innehåller mindre än 10 000 produkter, då sker uppladdningen ganska snabbt, och detta kommer inte att påverka hastigheten på webbbutikens webbplats på något sätt.

Vid ett stort utbud ( mer än 10 000 produkter), är nödvändigt ytterligare anpassning Agent på Cron. För denna artikel måste du också ange namnet på den speciella exportprofilen.

4. Indikation på omedelbar lossning

Som ett resultat av inställningen av flaggan "Unload now", kommer katalogstrukturen att laddas ur i ovanstående fil, omedelbart efter installation av modulen.

Efter att ha laddat upp katalogen till en fil i systemet måste du gå till Administration -> Butik -> Butiksnamn -> "Katalog"-fliken och markera rutan "Ladda ner katalog från ICML nu". I det här fallet börjar nedladdningen av filen och bearbetningen av den nästan omedelbart.

5. Ange ett profilnamn

Efter korrekt inställning av uppladdningen av produktkatalogen, kommer en ny typ av systemexport att visas i avsnittet Butik > Inställningar > Dataexport; om periodisk uppladdning anges under installationen kommer även en exportprofil att visas.

Notera:
För självkonfiguration uppladdning är det möjligt att skapa din egen exportprofil.

Slutför installationsguiden

I slutet av installationen kommer 2 agenter att skapas: en agent laddar upp orderhistoriken från Bitrix till systemet, den andra agenten genererar en katalog. Om beställningsuppladdning är konfigurerad för en agent, laddas beställningar upp till systemet när historiken anropas. I andra fall lossas beställningar baserat på en händelse.

Lossning av leveranstjänsten under utbytessystemet 1C-Bitrix

Om du har automatiserade leveranstjänster kopplade till 1C-Bitrix, såsom eDost, som har många profiler: Russian Post, EMS, DHL och många andra, så kan du i systemet dra nytta av möjligheten att ladda upp denna typ av leveranstjänst.

Leveranssätt måste konfigureras på systemsidan. Om systemmodulen installerades innan leveranstjänsten kopplades till Bitrix, måste de saknade leveranssätten matas in i systemet manuellt. Om modulen installerades efter att leveranstjänsten anslutits, kommer leveransmetoderna att installeras automatiskt, liksom själva tjänsten lossar. Det vill säga, för varje beställning kommer leveranskostnaden att laddas ner.

På 1C-Bitrix-sidan måste du göra följande inställningar om systemmodulen installerades efter anslutning av leveranstjänsten till 1C-Bitrix-systemet:

Gå till Administration > Inställningar, gå till fliken "Kataloginställningar".

Konfigurera leveransmetodernas överensstämmelse (preliminärt konfigurerad på systemsidan). Klicka sedan på knappen "Ladda upp leveranstjänster".

Ställa in frekvensen för uppladdning av 1C-Bitrix - system

Vid uppdatering av produktkatalogen kan två punkter markeras:

Kataloggenerering (i yml/icml-format) på klientsidan och

Systemet laddar ner katalogen en gång var tredje timme. Sökvägen till filen som behöver laddas upp ställs in i butiksinställningarna - du måste gå till avsnittet Administration > Butiker > Välj butik > Katalogfliken.

Efter installation av systemmodulen i 1C-Bitrix skapas en profil för uppladdning. För att se måste du gå till Desktop > Butik > Inställningar > Dataexport. Skärmdumpen visar två alternativ:

Standard,

Laddar upp systemkatalogen.

Om du väljer det andra alternativet öppnas uppladdningsalternativen genom att klicka på det.

Om Agent är valt som frekvensalternativ måste du gå till för att se listan över agenter Desktop > Inställningar > Produktinställningar > Agenter.

Om du klickar på "Ändra" eller "Lägg till ny" kan du tilldela eller ändra frekvensen för att köra genereringsuppgiften.

Frekvens för datasynkronisering under utbyte 1C-Bitrix - system

Systemmodulen låter dig ladda upp en produktkatalog till ditt system, samt utföra regelbundet tvåvägsutbyte av order och kunder.

Genom att ladda upp data från katalogen i tid kommer dina systemansvariga att ha uppdaterad information om produkttillgänglighet. En situation där en produkt beställs, och efter en tid visar sig att den är slut i lager, kommer inte att uppstå.

Orderutbyte är en process för datasynkronisering när beställningar laddas upp i båda riktningarna:

Från 1C-Bitrix till systemet:

  • Om uppladdning av händelser är aktiverad, när du skapar eller ändrar en beställning i 1C-Bitrix-systemet, kommer den omedelbart att laddas upp till systemet. Om ett lossningsagent väljs kommer beställningen att laddas upp till systemet inom 15 minuter (det rekommenderas inte att använda denna mekanism utan tvingande skäl, eftersom i det här fallet kommer beställningar att anlända med en fördröjning och uppdateringar av dessa beställningar kommer inte att överföras till systemet).
  • När en användare ändrar sig kommer även stamdata omedelbart att laddas upp till systemet.

Från systemet till 1C-Bitrix:

  • Om du skapar en beställning i systemet för en ny användare, kommer beställningen att laddas upp till 1C-Bitrix och skapas Ny användare i intervallet från 1 till 15 minuter.
  • Om du ändrar adress, leveranskostnad eller status i systemet på beställningssidan, kommer alla dessa ändringar att laddas upp till 1C-Bitrix inom 15 minuter.
  • Om du ändrar produktrabatter i systemet och ändrar mängden produkter kommer detta att ändras i 1C-Bitrix i intervallet från 1 till 15 minuter.

Ändringar i integrationsmodulen

Version 2.0

  • Integrationsmodulversionen V2.0 är utformad för att integrera 1C-Bitrix med modulversionen för "Onlinebutik (rea)" > 16 installerad i den.
  • Nu fungerar modulen via API V4.
  • Integrationsmodulen använder nu den nya 1C-Bitrix D7-kärnan.
  • Nu skickas även ändringar gällande klienten (fullständigt namn, e-post, telefon) till hemsidan från systemet.
  • I integrationsmodulinställningarna i avsnittet "Övriga inställningar" blev det möjligt att översätta ordernummer från systemet till 1C-Bitrix. Det vill säga om du manuellt skapar en order i systemet med numret, till exempel 12345R, så kommer en order med samma nummer att skapas i 1C-Bitrix.
  • Eftersom Bitrix-utvecklare i modulen "Onlinebutik (rea)"-version > 16 gick bort från att tillämpa rabatter på hela beställningen och lämnade rabatter endast för produkter, har systemet för närvarande inte heller möjlighet att använda rabatter till hela beställningen. Du kan ställa in rabatter endast för specifika beställningsartiklar.

Version 2.1

  • Lade till måttenheter i katalogexport.

Version 2.2

  • Modulen stöder nu flera API-versioner med ett val.
  • API V5-stöd.
  • Lade till möjligheten att lossa saldon efter lager.
  • Lade till möjligheten att ladda ner pristyper.
  • Lade till grundläggande Daemon Collector-integration.
  • Lade till integration med Universal Analytics.
  • Logiken i de inbyggda funktionerna för datamodifiering har förbättrats.
  • Lade till inbyggd funktion retailCrmApiResult.
  • Lade till utlösande version av ändringshistorik.

Version 2.4

  • Lade till en check i processorn för att spara betalning för en ny beställning.
  • Tillagd inställning för antalet handelserbjudanden vid export.
  • Tillagd köppriskonvertering.
  • Ändra översättningsfiler.
  • Lade till en bock vid avlastning av ändringar från systemet för orderegenskaper.
  • Lade till momsuppladdning.
  • Fixat att få en lista över pristyper för uppladdning. Alla typer som finns tillgängliga i Bitrix är tillgängliga för val.

Andra inställningar

Beställningsinställningar

Överför ordernummer som skapats i centralen till butiken

När en order skapas i systemet genererar den ett eget unikt nummer enligt de angivna reglerna. När denna inställning är inställd i modulen kommer numret på en sådan order att överföras till butiken under omvänd synkronisering.

Lossar order

  • Efter händelse- när du sparar beställningen går data in i systemet;
  • Ombud- nya beställningar skickas innan ändringshistoriken begärs från systemet.

Client API-version

Nu kan du välja vilken API-version som modulen ska fungera med. Valet beror på systemversionen. Det rekommenderas att välja den senaste versionen.

Aktivera avlastning av saldon per lager (tillgängligt om lager finns)

Nu kan du periodiskt lossa saldon från platslager till systemlager. För att göra detta behöver du:

  • jämför platslager med systemlager;
  • indikera systembutikerna i vilka saldon kommer att laddas;
  • välj informationsblock med varor som behövs för lastbalanser (du måste välja de som anges i katalogexporten för systemet).

Uppladdningen utförs av agenten med en frekvens på 1 timme (som standard).

Observera att för att ladda balanser i systemet måste alternativen vara aktiverade.

Aktivera uppladdning av pristyper för produkter (endast tillgängligt om det finns flera pristyper)

Nu kan du periodvis ladda upp ytterligare pristyper från butiken till systemet. För att göra detta behöver du:

  • jämför pristyper för webbplatser med systempristyper;
  • ange i vilka systembutiker ytterligare pristyper kommer att laddas in;
  • välj informationsblock med produkter som kräver laddning av ytterligare pristyper (du måste välja de som anges i katalogexporten för systemet).

Uppladdningen utförs av agenten var 24:e timme (som standard).

Aktivera Demon Collector

Nu kan du lägga till Collector Daemon till webbplatsen från inställningsgränssnittet. För att göra detta måste du ange lämplig nyckel för den önskade platsen. Nyckeln finns i systemet.

Aktivera UA-integration

Nu kan du aktivera integration med Universal Analytics från inställningsgränssnittet (fungerar korrekt med standardbeställningskomponenten). För varje webbplats som du vill lägga till spårning på måste du fylla i spårnings-ID och anpassat parameterindex.

Där $order är den genererade uppsättningen av orderdata som ska skickas till systemet, och $arFields är en uppsättning orderfält på webbplatsen. function retailCrmBeforeOrderSave($order) ( //Dina ändringar returnerar $order; //eller returnerar falskt; och sedan kommer ändringar från systemet för denna order att ignoreras)

Där $order är en array med modifierad orderdata som tas emot från systemet.

funktion retailCrmAfterOrderSave

retailCrmAfterOrderSave - en funktion som körs omedelbart efter att ändringar av orderdata som tas emot från systemhistoriken har sparats på webbplatsen.

function retailCrmAfterOrderSave($order) ( //Dina ändringar returnerar; )

Där $order är en array med modifierad orderdata som tas emot från systemet.

Funktion retailCrmApiResult

retailCrmApiResult - en funktion som körs omedelbart efter att ha mottagit ett svar från systemets API.

function retailCrmApiResult($methodApi, $res, $code) ( //Dina ändringar returnerar; )

Där $methodApi är namnet på API-metoden, $res är resultatet av sann/falsk begäran (lyckad eller misslyckad begäran), $code är API-svarsstatuskoden.

Observera att fel i koden när du använder denna funktion kan störa synkroniseringen av webbplatsen och systemet.

Om verktygen som listas ovan inte räcker av någon anledning kan du göra de nödvändiga ändringarna direkt i modulkoden utan att riskera att förlora dessa ändringar när du uppdaterar modulen. För att göra detta måste du kopiera filen med den nödvändiga klassen till katalogen /bitrix/php_interface/retailcrm/ och göra ändringar i den. Denna mekanism stöder byte av klasser för att fungera med kunder, beställningar, evenemang, katalogexport och andra hjälpmekanismer.


Bokmärke Anpassade uppgifterär avsedd för dem som direkt ska arbeta med produkten, det vill säga för anställda på företag som använder vår mjukvaruprodukt.

Fliken Administrativa uppgifter är avsedd för dem som ska administrera den förpackade versionen "Bitrix24".

Bokmärke Dokumentation avsedd för utvecklare av projekt baserade på den förpackade versionen "Bitrix24".

Anpassade uppgifter

Administrativa uppgifter

För utvecklare

Utvecklardokumentation är en beskrivning av systemets API. Användardokumentation är en beskrivning av systemkomponenter och inställningar.

Dokumentationen finns tillgänglig både online och som fil i chm-format. Det rekommenderas att använda onlineversionen eftersom den är mer uppdaterad. chm-filer uppdateras med jämna mellanrum och kanske inte innehåller information om de senaste versionerna.

Uppmärksamhet! Om du inte ser innehållet i formatfilen .chm, då är anledningen säkerhetsinställningar operativ system. I filegenskaperna måste du avblockera filen från visning. Läs mer iFAQ

Dokumentation är referensinformation. Det räcker inte för en nybörjare att arbeta med systemet. Att bemästra principerna för programmering i Bitrix ramverk En speciell kurs hjälper dig:

För inte så länge sedan fick vårt företag en ganska stor webbutik på 1C-Bitrix för underhåll och modifiering. Projektet sattes i kommersiell drift för ett par månader sedan, men hade samtidigt en rad allvarliga problem. Dessutom planerade kunden att slutföra den nya funktionaliteten så snabbt som möjligt. Jag fick i uppdrag att organisera effektivt arbete enligt projektet med minimal driftstopp och maximal tillfredsställelse av kundernas behov.

Initial data:

  • Det finns en webbutik på 1C-Bitrix
  • Projektet är flera år gammalt, men för bara några månader sedan överfördes sajten till 1C-Bitrix
  • Närvaro 10-15 tusen personer per dag
  • Butikskatalogen innehåller cirka 12 000 produktartiklar
  • Driftstopp och webbplatsavbrott är oacceptabla
  • Projektet utvecklades av ett annat företag inom sex månader:
    1. Det finns en teknisk specifikation för cirka 100 ark, motsvarande cirka 40 % av det utförda arbetet.
    2. Ingen projektdokumentation
    3. Bristande förståelse varför tidigare utvecklare använde specifika arkitektoniska lösningar.

Utveckling programvara Generellt, och webbprojekt i synnerhet, har jag arbetat med webbprojekt i ca 8 år. Under denna tid stötte jag på projekt av varierande komplexitet och vid en första anblick verkade jag inte alltför svår uppgift. Vid genomförande av projekt i vårt företag används som regel SCRUM-metoden. Jag började trycka ifrån henne.

Först och främst fick jag tillgång källkod projekt. Ytligt analyserad. Kom överens med kunden om listan över prioriterade arbetsuppgifter. Jag gjorde en utvecklingsplan för 3 utvecklare och, som Gagarin sa, låt oss gå!

Problem #1 – utvecklarna är skyldiga till allt

Som vanligt är alla skyldiga utom kunden. Designern gjorde en layout som väger för mycket, hostaren tillhandahöll en server som fungerar långsamt, utvecklarna gjorde en webbplats som är buggig och trasig hela tiden, cheferna slutförde några uppgifter som vi inte bad om att få utföras efter att ha bytt från gammal version webbplats på 1C-Bitrix var det en kraftig minskning av söktrafiken osv. Situationen är inte entydig. Å ena sidan bör huvudansvaret givetvis ligga på utvecklarföretaget. Det var nödvändigt att förmedla till kunden konsekvenserna av alla åtgärder med webbplatsen och förbereda sig för resultatet. När du utför arbete, föreslå en holistisk arkitektur framtida system och en utvecklingsplan att följa tills milstolpar är slutförda. Genomför noggranna tester av funktionaliteten och lämna in arbetet. Å andra sidan stöter jag ofta på en situation där kunden vet allt bättre själv, eftersom hans mamma en gång målade, och därför är bästa designern, och hans 7-årige son är väl insatt i SEO-optimering, eftersom han spenderar all sin tid på datorn och spelar GTA.

Det är inte för oss att bedöma vem som är skyldig och vem som har rätt. I det här fallet var den tidigare entreprenören ett ganska välkänt, pålitligt företag och jag kan inte säga något dåligt om deras utveckling. Och kunden, objektivt sett, bryr sig om sin produkt och försöker förbättra den. Jag vet inte hur det gick till, för mig själv hittade jag en förklaring i den otillräckliga mängden analys som entreprenören tillhandahållit kunden.

Som ett resultat:

  • Projektet har inte kommit till sin logiska slutsats. Många uppgifter överges halvvägs
  • Projektet är inte dokumenterat. Funktionen för en del av funktionerna är inte uppenbar. När man utvecklar en ny funktionalitet visar det sig att funktionalitet som tidigare fungerade och som den nya utvecklaren inte misstänkte att den har slutat fungera
  • En del av koden som skrivits av den tidigare artisten måste skrivas om från grunden
  • Den planerade arkitekturen för projektet är inte tydlig för den nya entreprenören under de första veckorna/månaderna av arbetet. Förbättring av funktionaliteten hos en modul leder till förlust av funktionalitet hos en modul som inte på något sätt är relaterad till den.
  • Kunden är nervös, artisten är nervös, besökarna är inte nöjda, närvaron minskar, försäljningen sjunker

Jag ser bara en lösning på problemet: rensa gradvis systematiskt ut alla platsmoduler en efter en för att få produkten till önskat tillstånd. Vissa fel inkluderades i separata uppgifter och slutfördes omedelbart, andra korrigerades parallellt med utvecklingen av ny funktionalitet. Resultatet är att med varje uppdatering, efter att ha rensat ut buggar omgående, blir sajten bättre och mer stabil.

Problem #2 – parallell utveckling.

I enlighet med 1C-Bitrix licenspolicy tillåter varje webbplatslicens dig att använda 2 exemplar av systemet. En som produktionsplats, den andra för utveckling. Problemet är att utvecklingen utförs av flera, i mitt fall tre, utvecklare kontinuerligt. När det gäller klassisk utveckling är allt enkelt. Varje utvecklare arbetar på sin egen modul. Sedan utförs funktionstestning av varje modul, alla förbättringar slås samman i arkivet för något versionskontrollsystem, sedan testas det alla tillsammans (integrationstestning). Om resultatet är normalt presenteras testversionen för kunden. Efter att testversionen har godkänts uppdateras produktionsservern. I enlighet med SCRUM-metoden bestämde jag att jag skulle ladda upp nya versioner till produktionsplatsen en gång i veckan. Följaktligen finns det 3-4 dagar för grundläggande utveckling. 1 dag för testning och buggfixar och en halv dag för uppdatering av produktionsservern. Tidsfristerna varierar naturligtvis, men jag försökte strikt följa regeln "släpp varje torsdag".

Det första jag stötte på var att i 1C-Bitrix finns det situationer där samma fil samtidigt används i olika funktionalitet i olika ändar av sajten. Den enklaste och mest uppenbara lösningen är att använda ett versionskontrollsystem, i mitt fall SVN, som jag använder i alla andra projekt. Men för att använda versionskontroll är det nödvändigt att varje utvecklare har sin egen version av koden, som han redigerar och sedan sammanfogar i det gemensamma arkivet.

Hur är det med licensen? Kontaktade teknisk support 1C-Bitrix. Jag fick ett erbjudande om att köpa ytterligare. licenser för utveckling. Jag var milt uttryckt inte nöjd, men jag fick inga andra erbjudanden. Jag hittade en lösning snabbt nog. Jag bestämde mig för att använda NFR-nycklar. Lyckligtvis tillåter partnerstatus det. Som ett resultat skapade jag 5 installationer på nätet:

  • Produktionsserver
  • Testserver
  • 3 utvecklingsservrar (en per utvecklare)

Med tiden gick jag ännu längre. Det finns även en separat installation för testaren. Det visade sig att med min tur loggar kunden alltid in på testservern i det ögonblick som något uppdateras där. Buggspåret innehåller många onödiga uppgifter som redan är genomförda och kunden får intrycket att vi gör vårt jobb dåligt.

För närvarande använder jag följande schema:

  • Varje utvecklare använder bara sin lokala kopia för arbete
  • Vid överenskommen tidpunkt slås alla genomförda förbättringar samman till en gemensam gren i förvaret
  • QA tar den sammanslagna versionen för testning
  • Efter att ha testat och åtgärdat fel uppdateras demoservern för kunden
  • Efter verifiering och acceptans av kunden överförs förbättringar till produktionsservern.

Bland de uppenbara nackdelarna med detta tillvägagångssätt vill jag lyfta fram den låga nivån av kundengagemang i utvecklingen. Resultatet är synligt för kunden först i slutskedet. Detta tillvägagångssätt är tillämpbart om du har en bra analytiker som sällan gör misstag och har ständig kontakt med kunden. Annars kommer många uppgifter att behöva göras om från grunden.

När jag byggde kretsen stötte jag på ett annat problem. Projektet tar upp cirka 80 GB diskutrymme. Utan cache och temporära filer - cirka 60. Först försökte jag ta bort bilder och videor från versionskontrollen - det fungerade inte. Informationen på sajten ändras ständigt. Du måste testa med aktuella data. Den första commit till arkivet tog mig mer än 2 dagar i bitar. Den första utcheckningen till utvecklingsmappen tar flera timmar (SVN-server in lokalt nätverk utveckling). Om du, gud förbjude, av misstag gör en komplett uppdatering av projektmappen kan du åka iväg och röka, äta lunch, spela pingis eller curling. Att endast begå utvalda filer eller mappar går ganska snabbt. Lösning: Jag slutförde uppgiften att ladda ner ett dussin ändrade filer på en gång.

Problem nr 3 – uppdatera produktionsservern och samarbeta med kunden

Problemet är det viktigaste, komplexa och inte helt löst. När allt kommer omkring, om andra problem hänför sig till projektets interna arbete, beror kundens rykte och inkomst, och följaktligen min inkomst, på webbplatsens arbete.

Murphys lagar fungerar utmärkt här:

  • Om något inte fungerar bra på testservern kommer det definitivt att gå sönder på produktionsservern.
  • Om något fungerar perfekt på testservern kommer det fortfarande att gå sönder på produktionsservern.
  • Om en bugg på webbplatsen bara existerar i 5 sekunder, kommer en av besökarna definitivt att hitta den och kommer definitivt att skriva om den i recensioner eller i feedbackformuläret.
  • Om sajten inte fungerar på 1 minut under en uppdatering så är det i denna minut som företagsägaren kommer att visa den för sin vän eller konkurrent (och detta trots överenskommelse om tid och tillvägagångssätt för uppdateringen).
Visst överdriver jag, men varje skämt har lite humor i sig. Minsta belastning på platsen är från 4 till 6 på morgonen. Naturligtvis skulle det vara bättre att uppdatera nu, men jag vill verkligen inte.

För de flesta webbapplikationer finns det en tydlig struktur för att dela upp applikationen i lager och uppdatering av webbplatsen kan delas upp i 2 delar:

  • Koduppdatering
  • Uppdatering av databasen med SQL-skript

När det gäller 1C-Bitrix är allt lite mer komplicerat. För det första finns det många filer. Jag har mer än en miljon av dem i mitt projekt. En typisk uppdatering från förvaret tar inte mindre än 20-30 minuter. Du kan naturligtvis bara uppdatera de ändrade filerna, men då är hela poängen med förvaret förlorad. För det andra, och detta är mycket mer tråkigt, ofta när du uppdaterar måste du göra manuella ändringar och inställningar via adminpanelen. Och det här är alltid långsamt, du måste komma ihåg alla ändringar som måste göras, det finns en stor sannolikhet att av misstag göra ett misstag. Du kan naturligtvis skriva ett SQL-skript som gör alla nödvändiga ändringar i databasen. I de enklaste fallen gör vi förstås just det. Men i de flesta fall tar att skriva och felsöka ett sådant skript mer tid än själva utvecklingen och mycket mer tid än att utföra alla åtgärder manuellt med efterföljande testning.

Jag har inte hittat någon bra lösning på problemet än. Nu uppdaterar vi inställningarna i databasen manuellt. För att minimera fel sammanställs en checklista med en lista över vad som behöver göras under uppdateringen. Vi försöker utföra uppdateringen så noggrant och korrekt som möjligt. Efter uppdateringen kontrollerar hela teamet produktionsserverns huvudfunktionalitet och genomför ytterligare tester. Antalet fel har minimerats, men det har ännu inte varit möjligt att helt bli av med buggar och driftstopp under uppdateringen.

Det andra jag stötte på är samarbete med kunden. Därför att Projektet är stort, ett 30-tal personer jobbar ständigt med det. Innehållshanterare, försäljningschefer, SEO-optimerare, marknadsförare och många andra. Naturligtvis gör alla vissa ändringar på webbplatsens sidor och modulinställningar. Det första beslutet var att ta rätten från kunden att göra ändringar i sajtens programkod. Beslutet var helt korrekt, men det blev bara värre. Om kunden tidigare antog att han också kunde gå till platsen och av misstag bryta något, började nu alla problem falla bara på oss. Vad har det med saken att göra. Även om innehållshanteraren redigerade texten på sidan snett och inte stängde någon tagg, är det fortfarande utvecklaren som bär skulden. Lösningen visade sig vara ganska enkel. Marknaden har en gratis modul för sidversionskontroll. Detta löste inte problemet, någon kommer fortfarande att förstöra något då och då, men nu är det möjligt att när som helst se vem som ändrade vad de ändrade och varför allt gick sönder. Resultatet är förstås inte is, men det sparar mig en hel del nerver.

Dessutom beslutade vi att före varje uppdatering av testservern tar vi en kopia från produktionsservern till den. Detta tar också mycket tid. Arkivera projektet, överför det till en annan server, packa upp det. Allt detta tar flera timmar. Men nya förbättringar testas praktiskt under stridsförhållanden. Om inställningarna för test- och produktionsservrarna är identiska blir skillnaden i drift minimal och antalet fel kommer att minska avsevärt. Erfarenheten har visat att produktionsservern på en vecka kan förändras så mycket att en del av den nya funktionaliteten som fungerar utan problem på en veckogammal kopia kanske inte fungerar alls på en färsk kopia.

Problem #4 - "gör det åt mig brådskande, det här är en 5-minutersuppgift"

Problemet är inte så mycket relaterat till 1C-Bitrix, utan till förfining och stöd för fungerande projekt. Ofta har kunden en önskan att göra någon liten sak, men brådskande och omedelbart på produktionsplatsen. Resultatet är alltid detsamma – inget gott kommer ut ur det. I bästa fall kommer denna modifiering helt enkelt att glömmas bort under nästa utgåva, i värsta fall kommer servern helt enkelt att krascha och måste återställas från backup i flera timmar.

Jag hittade bara en lösning - följ aldrig kundens ledning på bekostnad av tillförlitlighet och säkerhet. Oavsett hur kunden frågar kommer utvecklaren alltid vara skyldig. Som min tidigare chef sa till mig: "Jag bad dig inte göra något dåligt."

Och eftersom vi berörde ämnet säkerhetskopior vill jag notera. Säkerhetskopiering med 1C-Bitrick är förstås bra och bekvämt, men väldigt långsamt. Om du akut behöver återställa 1-2 filer eller flera värden i databasen måste du vänta tills alla 60 GB har packats upp. Följande schema förefaller mig vara det mest effektiva:

  • Det ska finnas en daglig säkerhetskopia av filer och databaser i form av ett arkiv på extern källa data.
  • Vi gör alltid en säkerhetskopia omedelbart före uppdatering i ett av två alternativ:
    1. Alternativlampa – Kopiera hela projektmappen till en intilliggande mapp på servern. Vi sparar databasen som en dump i en separat fil. Vi arkiverar ingenting. Om du behöver återställa något värde i databasen eller en av filerna, kommer allt att finnas till hands och lättillgängligt
    2. Alternativ stark - liknande den föregående, bara vi kopierar databasen till en annan databas MySQL-data. Detta kommer att tillåta, i händelse av en fullständig krasch, att korrigera webbplatsens rotmapp i hosts-filen på 1-2 minuter, och projektet kommer att börja arbeta från en närliggande mapp med en kopia av databasen.

Slutsats

Tack till alla som läst till slutet. Jag hoppas att min erfarenhet kommer att vara användbar för dig. Jag tar gärna emot förslag på bättre sätt att lösa de problem som tas upp i kommentarerna eller i ett personligt meddelande. Nu har jag försökt uttrycka de största problemen med att slutföra och stödja redan lanserade projekt med höga krav på tillförlitlighet. Om materialet visar sig vara intressant planerar jag att skriva en fortsättning om funktionerna i 1C-Bitrix-arkitekturen som skiljer utvecklingen av en webbplats på Bitrix från utvecklingen av andra webbprojekt.

Information om att arbeta med finns i handledningarna och dokumentationen. Utbildningar är utformade för att behärska arbetssätt inom mjukvaruprodukt, och dokumentation - för att behärska principerna för CMS-anpassning.

När man arbetar med "1C-Bitrix: Site Management" problem uppstår i form av specifika praktiska problem. Vi har samlat in i specialiserade ämnen olika sidor utbildningar för att göra det lättare för dig att hitta svar på dina frågor.
Utbildningscentra Ställa en fråga Forum



Bokmärke Innehållshanterareär avsedd för dem som direkt ska arbeta med produkten, det vill säga för innehållshanterare som leder projekt skapade på vår mjukvaruprodukt.

Bokmärke Administratörer avsedd för dem som ska administrera "1C-Bitrix: Site Management".

Bokmärke För utvecklare designad för projektutvecklare baserat på "1C-Bitrix: Site Management".

Innehållshanterare

Du kan importera kursen till din webbplats Innehållshanterare från detta arkiv. Kurs utan frågor för prov.
Kursversion daterad 5 juni 2015.

Administratörer

För utvecklare

Utvecklardokumentation är en beskrivning av systemets API. Användardokumentation är en beskrivning av systemkomponenter och inställningar.

Dokumentationen finns tillgänglig både online och som fil i chm-format. Det rekommenderas att använda onlineversionen eftersom den är mer uppdaterad. chm-formatfiler uppdateras regelbundet och kanske inte innehåller information om senaste ändringarna i hjälpsystemet.

Uppmärksamhet! Om du inte ser innehållet i formatfilen .chm, då är anledningen säkerhetsinställningarna för operativsystemet. I filegenskaperna måste du avblockera filen från visning. Läs mer iFAQ

Dokumentation är referensinformation. Det räcker inte för en nybörjare att arbeta med systemet. Att bemästra principerna för programmering i Bitrix ramverk En speciell kurs hjälper dig:

Populär i kategorin:
Hur skapar man ett karaokeklipp på en dator?
Hur skapar man ett karaokeklipp på en dator?
läsa
Origin-appen krävs för spelet, men den är inte installerad. FIFA 16 kräver Origin.
Origin-appen krävs för att spela, men den är inte installerad FIFA...
läsa
Registrera en personlig sida på det sociala nätverket Facebook
Registrera en personlig sida på det sociala nätverket Facebook
läsa
Hur man kör en enkel Nmap Nmap Scan
Hur man kör en enkel Nmap Nmap Scan
läsa

Senaste artiklarna
Hur man roterar en bild några grader...
läsa
Inaktiverar annonsering i Yandex webbläsare Där...
läsa
Felsöker problem med Wi-Fi-anslutningen på...
läsa
Byt lösenord på Windows 10-profilen
läsa
Instruktioner för att ställa in trådlösa routrar...
läsa
Hur man väljer en hårddisk och vilken är bättre att köpa...
läsa
Meizu för dummies. Samtal och adressbok....
läsa
Ladda ner programmet PDFMaster
läsa
Topp