Управлението на изданията, както подсказва името, е процесът на управление, планиране, планиране и контрол на изграждането на софтуер през различни етапи и среди; включително тестване и внедряване на софтуерни версии (Humble & Farley, 2011).
работа с дати в javascript
Това е доста голяма тема сама по себе си и може да бъде усъвършенствана с течение на времето само чрез изпробване на различни итерации с екипите за разработка и съвпадение на бизнес нуждите или изданията на функции. Ще се опитаме да обхванем индустриалните практики за управление на метаданни, изграждане на CI и управление на пясъчници за управление на организацията освободете влака .
Но какво е освобождаващ влак?
Освобождаващ влак е постепенна и предсказуема техника за предоставяне на функции. Той изисква от разработчика да създаде официален процес, за да вземе всички промени, направени в средата за разработка, и да ги внедри в производството.
Освобождаващ влак може най-общо да бъде разделен на три сегмента:
- Управление на метаданни
- Непрекъснато изграждане на интеграция
- Управление на пясъчника
Управление на метаданни
Метаданните са данни, които предоставят информация за други данни. Salesforce предоставя богат и мощен модел на метаданни чрез своя API за метаданни . Метаданните на вашето приложение описват и обхващат набор от методи, които осигуряват програмен достъп до изходния код и конфигурацията на вашата организация.
The API за метаданни е най-добрият начин за управление на персонализациите в Salesforce. Той поддържа create, read, update и delete методи. Можете да използвате Change Sets, Force.com IDE и Ant Migration Tool за мигриране на метаданни от една организация в друга, тъй като всички те предоставят миграции чрез API.
Всеки инструмент има своите предимства и има няколко неща, които трябва да се вземат предвид при избора на един:
Таблица 1: Сравнение на инструментите за миграция на метаданни
| Промяна на комплекти | Force.com IDE | Инструмент за миграция на мравки |
|---|---|---|
| Наборите за промяна са начинът за разполагане на компоненти чрез стандартния потребителски интерфейс на Salesforce. | Force.com IDE (Eclipse) е предназначен предимно за разработка на Apex, но може да се използва за целите на внедряването. | Ant Migration е мощен инструмент за команден ред, предназначен за мигриране на промени / метаданни между среди. |
| Обикновено се използва за малък брой миграции на компоненти. | Разработчиците обикновено използват IDE за мигриране на промени в тестовата или променителна среда. | Ant Migration се използва за мигриране на голям полезен товар и се нуждае от усъвършенствани познания за API за метаданни на Salesforce. |
| Връзката между организациите трябва да се установи ръчно, така че не е подходяща за автоматизирано разполагане. | Може да се използва за разполагане във всяка организация, но се нуждае от някои ръчни стъпки, които са склонни към грешки. | Автоматичните разполагания могат да бъдат планирани много лесно. |
| Предназначен за използване от администратори. | Насочен към разработчиците на salesforce, тъй като разработването на кода е основното му използване. | Насочен към инженерите на DevOps. |
| Добавянето на зависимости е много лесно и удобно за потребителя. | Добавянето на зависимости е донякъде лесно, тъй като предоставя потребителски интерфейс за точка и кликване. | Внедряването обикновено се проваля поради липсващи зависимости. |
| Не позволява разрушителни промени. | Позволява деструктивни набори от промени, но процесът е доста досаден. | Позволява деструктивни набори от промени. |
API за метаданни отлично изпълнява целта си при разработване и мигриране на промени на платформата Force.com. Но има лек улов - не всички метаданни на Salesforce се поддържат от API за метаданни. Официалната документация предоставя a списък на неподдържани компоненти.
Ако вашата организация прави промени, които не се поддържат от API за метаданни, трябва да се уверите, че репликирате тези промени ръчно в целевата организация. Най-добрият начин за проследяване на тези промени е електронната таблица. Ако трябва да прибегнете до този подход, винаги е препоръчително за един човек да направи тези промени и да ги проследи.
Това би бил добър общ списък с колони, които бихте могли да използвате за проследяване на тези промени в електронна таблица:
- Име на компонента
- Тип на компонента
- Промяна на собственика
- Описание на функционалността
- Картографиране на възможностите
- Зависимост от други компоненти
- Прегледано / рецензиращо име
- URL
- Име / идентификационен номер на организацията
- Други коментари
Контрол на версиите и непрекъсната интеграция
Мигрирането на промените към производството трябва да бъде плавен процес, тъй като това е просто повторение на прилагането на промени в тестовата и променителна среда. Все пак винаги има шанс нещата да отидат на юг и тогава се нуждаете от резервен план. Много е важно да запазите резервно копие на метаданните на организацията си и ето какво контрол на версиите и CI изграждане са за.
Контролът на версиите е абсолютно задължителен за всяка организация. Тя позволява на разработчиците да работят по съвместен, ефективен и безопасен начин. Управлението на мулти-разработчик, мулти-пясъчник разработка и миграция е предизвикателство в Salesforce. Salesforce също има свой график за издания и поддръжка. Тези актуализации предоставят нови функции, но те могат да въведат промяна в API за метаданни, която може да наруши вашата CI компилация. Така че, освен ситуациите, в които разработчиците презаписват промените помежду си, контролът на версиите ви помага при изграждането на стратегия за връщане. Наличието на стратегия за връщане е задължително, когато приложението ви се изпълнява на Force.com.
Следващата блок-схема показва практическа структура за управление на версиите и CI. Ще се опитаме да ви дадем кратко описание на това, какво представлява диаграмата.
- Разработчик ще провери промяната им в системата за контрол на версиите.
- CI сървърът / Jenkins ще внедри най-новата компилация в CI пясъчника и ще стартира тестови класове.
- Ако разполагането в стъпка 2 е успешно, тогава промените се обединяват в клон на QA.
- След това CI ще разгърне последния ангажимент от клон на QA в пясъчника на QA.
- Ако QA отхвърли промените поради неуспешни тестове, стъпки от 1 до 3 трябва да се изпълнят отново, докато QA изчисти промените.
- След като промените преминат тестване в QA, промените се обединяват в главния клон.
- Последните промени от главния клон са внедрени в пясъчника на Master.
Човек може да избере да добави още клонове в зависимост от нуждите на организацията. Но горната структура просто работи добре за структурите за развитие от средно до предприятие.
Управление на пясъчника
За да извлечете максимума от процеса на DevOps на вашата организация, е много важно да настроите структурата на пясъчника. Преди да се потопим много по-дълбоко в него, нека обсъдим различните видове пясъчници, които ни предлага Salesforce.
Пясъчникът е почти точно копие на производствените метаданни. Пясъчниците обикновено се използват за разработка, тестване, постановка и обучение. Има четири вида пясъчници и един трябва да обърне дължимото внимание при избора на пясъчник. Пясъчните кутии с пълно копие могат да струват много пари!
По-долу е таблицата за ограниченията, налагани от Salesforce за различни пясъчници.
Таблица 2: Сравнение на граници
| Разработчик | Програмист Pro | Частично копие | Пълно копие | |
|---|---|---|---|---|
| Данни за производството | Не | Не | Да | Да |
| Хранилище за данни | 200 MB | 1 GB | 5 GB (10 000 записа на обект) | Пълни данни |
| Период на опресняване | 1 ден | 1 ден | 5 ден | 29 ден |
Виждаме, че цената не е единствената разлика между пясъчниците.
Пясъчникът за разработчици има еднодневен период на опресняване, което го прави подходящ за разработка, но може да побере само 200 MB данни и никакви производствени данни. Като полярна противоположност, пясъчните кутии с пълно копие имат точно копие на производствените данни; дори идентификаторите на записите са еднакви. Това би могло да го направи чудесно за тестване и инсцениране, но периодът на опресняване от 29 дни затруднява получаването на най-новите производствени метаданни и данни в пясъчника с пълно копие.
Таблицата по-долу действа като основно правило за избор на пясъчници:
Таблица 3: Използвайте случаи за избор на пясъчник
| Разработчик | Програмист Pro | Частично копие | Пълно копие | |
|---|---|---|---|---|
| Развитие | Да | Да | Не | Не |
| QA | Да | Да | Да | Не |
| Тест за интеграция | Не | Не | Да | Да |
| Тест за партидни данни | Не | Не | Да | Да |
| Обучение | Не | Не | Да | Да |
| UAT | Не | Не | Да | Да |
| Тест за натоварване | Не | Не | Не | Да |
| Постановка | Не | Не | Не | Да |
| Обучение на потребителите | Не | Не | Не | Да |
По-долу е дадена типичната организационна структура, която е приета за средни проекти. За клиенти на ниво предприятие организационната структура става по-сложна, но като цяло следва модела по-долу.
Развитие на Salesforce обикновено се извършва в пясъчника на разработчика (червен) и промените се преместват в пясъчника за интеграция (зелен), който обикновено е професионален разработчик или пясъчник за частично копиране. След това промените от множество интегрирани пясъчници се преместват нагоре към сборния пясъчник (жълт), който трябва да бъде частичен пясъчник за копиране.
Ако вашата организация има някакви интеграции със системата на трета страна, която се нуждае от тестване на интеграция и тестване на натоварване, трябва да има стабилен набор от данни, който не се променя от издание на издание. Така че, по-добре е да имате пълно копие или частично копие за него.
След това тези промени се преместват в пясъчника на теста за интеграция, където се извършват тестове. След това промените се преместват в тестовата пясъчна среда, която трябва да бъде пълна пясъчна копия. Всички тестови класове се изпълняват преди разполагане. Трябва да се извърши валидиране на разполагане, за да се гарантира, че внедряването се случва без никакви проблеми.
Този процес ни помага да гарантираме, че промените преминават през множество кръгове на тестване и двойки очи. Той идва с тежък недостатък, изискващ много време за разработване, тестване и внедряване на промени.
Много често се налага спешна корекция на грешки или корекции. За да се справите бързо с тях, трябва да запазите пясъчник за разработчици, който да избутва малки петна директно в сборната пясъчник.
Както бе споменато по-рано, пясъчникът е почти точно копие на производствените метаданни, но не напълно. Има официален списък на компоненти / функции, които са деактивирани в пясъчник.
Друго нещо, което трябва да имате предвид, докато опреснявате пясъчника, е, че той копира само производствените метаданни и данни. Няма начин да копирате метаданните от една пясъчник в друга или дори да създадете празна пясъчник без никакви конфигурации на метаданни (като безплатни организации за разработчици). Това понякога се превръща в предизвикателство в реални житейски ситуации. Salesforce планира да реши този проблем и това особеност скоро може да стане общодостъпна.
Освен това, ако имате някои чувствителни данни в производството, които смятате, че вашият екип за разработка или тестване не трябва да има достъп, можете да създадете шаблони за пясъчник за напълно и частично копирани пясъчници.
Какво да имате предвид при внедряването
Покрихме отрасловите практики за управление на жизнения цикъл на приложенията в екосистемата Salesforce. Управлението на метаданни и пясъчник играе много важна роля при създаването на пакети за разгръщане и полезни товари. За големи и сложни Приложения на Salesforce , контролът на версиите помага да се гарантира, че промените в метаданните се проследяват, като същевременно помага при създаването на стратегия за връщане.
Управлението на пясъчника е критично за големи или сложни проекти. Но пясъчниците са скъпи в екосистемата Salesforce, както по отношение на финансовите ресурси, така и по отношение на времето. Формулирането на стратегия за управление на пясъчника винаги е от решаващо значение за процеса на управление на изданията.
Ще ви оставим някои допълнителни точки, които би било добре да имате предвид при следващото ви внедряване:
как да стартирате приложението angularjs
- Само 10 000 файла или 39 MB ZIP файл могат да бъдат внедрени едновременно. Естествено, ако полезният товар е твърде голям, трябва да разделите пакета на няколко части и след това да извършите внедряването.
- Ако разполагането е неуспешно поради
request timeoutгрешка, опитайте да премахнете обекти, персонализирани полета и профили от пакета. Разгръщането на тези компоненти отнема повече време. - Ако типът на полето се промени или е имало промени в йерархията на ролите, тогава може да има дълги закъснения поради преизчисляване на данни, изискващи известно време за завършване.
- Salesforce заключва всеки компонент, който в момента се използва от потребител в системата. Ако се опитаме да разположим, докато случаят е такъв, внедряването ще се провали.
Надяваме се, че този преглед ще ви помогне по време на следващото издание на Salesforce.
