В предыдущем разделе мы обсуждали требования к сайту. Здесь мы поговорим о том, как выполнить их технически. Остерегайтесь заявлений типа: «Мы хотим, чтобы все было так, как в текущей системе» – если только не вы ее создали! Если клиент этого хочет, убедитесь, что вы получили подробную информацию обо всем том, что должно быть в новой системе.

Рисунок 2.1. Любой, кто выбирает CMS, столкнется с массой опций. Чтобы решить, что сработает для вашего проекта, нужно понимать технические требования

Не сделаете этого – готовьтесь к тому, что перед самым запуском вас спросят: «А как эта система поддерживает задачу, которую пол-офиса делает каждый день?» (хоть это и не так на самом деле). И таким образом заставят вас вносить значительные дополнения в проект. Знаю это по своему опыту!

 

Управление контентом

 

Почти всем сайтам требуется та или иная форма управления контентом. Это может быть обновление страниц, добавление продукта в магазин или редактирование текста в приложении. В какой степени клиенту необходимо управлять контентом и кто будет его редактировать? В этом разделе мы будем использовать термин CMS в очень широком смысле, для описания любого инструмента редактирования контента – от простого текстового редактора до полнофункциональной корпоративной CMS бизнес-уровня.

Вот некоторые мысли по поводу выбора CMS:

• Всем ли редакторам (контент-менеджерам) нужны одинаковые права доступа?

• Будут ли управлять контентом специальные сотрудники или это станет частью работы других людей?

• Нужно ли поддерживать многоязычность?

• Какой тип контента будет редактироваться?

• Какие нужны средства редактирования?

 

Всем ли редакторам (контент-менеджерам) нужны одинаковые права доступа?

Итак, для работы на сайте нужен один редактор (например, владелец малого бизнеса) или несколько? Если второй вариант, то все ли редакторы будут иметь равные права? Или один будет иметь доступ к каким-то разделам системы, а другие нет?

Вот несколько сценариев:

• Сайтом большой компании управляет один человек, который утверждает весь контент, а в подготовке контента принимают участие несколько сотрудников. Клиент хочет, чтобы эти редакторы могли создавать контент и отправлять его на рассмотрение. После одобрения, он публикуется управляющим редактором.

• Компания хочет, чтобы отдел кадров мог публиковать и снимать вакансии на сайте и вел раздел, который касается вопросов найма сотрудников. У этих пользователей не должно быть прав для внесения изменений в другие разделы.

• Владелец сайта электронной коммерции не хочет, чтобы его редакторы имели доступ к собранным в системе отчетам по продажам или информации о покупателях. В то же время он хочет, чтобы его бухгалтер имел доступ к данным о продажах, и ни к каким другим больше.

• Владелец сайта хочет, чтобы все желающие могли писать в блог, но не трогали контент других разделов.

 

Будут ли управлять контентом специальные сотрудники, или это станет частью работы других людей?

Очень важно понять, что могут люди, которые создают и редактируют контент. Речь здесь не только о технических умениях, к примеру хорошо ли они знакомы с CMS, но и о том, насколько они чувствуют дизайн и контролируют, как все выглядит. Также проверьте их копирайтерские способности. Если вначале контент пишет опытный копирайтер, а после поддержкой занимаются владелец или сотрудник, не занимающийся копирайтингом, то CMS должна помочь импонять, что и как писать. Об этом – в статье «Ваша CMS как куратор дизайна и контента».

 

Нужно ли поддерживать многоязычность?

Даже если вы запускаете одноязычный сайт, но в ближайшем будущем нужно будет поддерживать несколько языков, подготовьтесь к этому заранее. Добавить на сайт поддержку нескольких языков гораздо сложнее, чем заложить эту функцию сразу. Конечно, это требование ограничивает выбор вариантов готового ПО.

Если сайт нужно переводить, выясните, как будет проходить этот процесс, чтобы поддерживать его в системе. Переводчики будут просто переводить весь контент в Word-документах или чем-то подобном, а потом отправлять редактору, чтобы он вносил их в систему? Не будет ли переводчику проще читать и переводить контент прямо в CMS?

 

Какой тип контента будет редактироваться?

У большинства сайтов, которым требуется CMS, относительно статические страницы и четкая стандартная древовидная структура. Наиболее логично создавать такой контент постранично, чтобы администраторы легко могли найти страницы для редакции.

В некоторых сайтах основная функция – блог и несколько поддерживаемых страниц. Тогда вы с заказчиком можете остановиться на использовании такой CMS, как WordPress. В ее ядре – функциональный и качественный блог, в ней также можно добавлять отдельные страницы.

Чем больше сайт, тем серьезнее требования к контенту. Например, сейчас мы переделываем сайт для фестиваля искусств. Многие годы фестиваль остается привлекательным за счет подборки ценных видео– и аудиоматериалов, а также тысяч высококачественных фотографий, которые ежегодно снимают профессиональные фотографы

В сайтах с постраничной структурой предполагается, что контент-редакторы будут каждый раз отыскивать в архивах важный материал и перезагружать его заново на сайт. В данном случае это не лучший способ. Вместо этого мы создали отдельный медиасервер, со средствами поиска и маркировкой материалов. Все это для того, чтобы их было легко находить и вставлять в страницу. CMS готовит фотографии нужных размеров, включая те, что нужны для адаптивного дизайна. Изучив архивы материалов и, оценив их объем, мы поняли возникающие в связи с этим проблемы. Это позволило нам предложить такое решение.

Есть сайты, которые больше похожи на веб-приложения, неважно, система ли это электронной коммерции, или традиционные приложения. Эти системы ориентируются не на постраничную структуру (хотя они и могут включать в себя некоторые страницы), а на различные виды контента, требующие обновления.

Слишком часто в таких системах небольшие тексты (например, текст на кнопке) жестко кодируются в самом приложении. И поэтому только разработчик может изменять текст в призыве к действию. В идеале должно быть так, чтобы рядовые пользователи могли его редактировать.

 

A/B-тестирование

На некоторых сайтах, в особенности на тех, что продают товары, вам нужно тестировать разные версии страниц, чтобы узнать, какой контент, макет страницы или взаимное расположение блоков приводит к большему числу конверсий.

В зависимости от типа сайта конверсии могут быть такие: покупка товара через сайт, подписка на получение пробной версии продукта, на e-mail-рассылку или заполнение формы. Если потребуется такой вид тестирования, как он будет осуществляться с помощью CMS? Если часть посетителей нужно отправить на одну версию страницы, а остальных – на другую, здесь не обойтись без стратегии. Об этом виде тестирования вы можете прочесть на сайте Smashing Magazine в исчерпывающей статье «Исчерпывающее руководство по А/В тестированию» либо на (примеч. ред.)

 

Электронная коммерция

Добавить функцию электронной коммерции на сайт может оказаться простым делом. Возможно, достаточно будет всего лишь поставить несколько кнопок «Купить сейчас» платежной системы PayPal. Но могут быть и трудности, например, если вам придется настраивать свой магазин на поддомене готовой платформы онлайн-магазина или разрабатывать свой собственный. Конечно, сегодня процесс продажи товара напрямую через сайт не надо усложнять. Но все же есть над чем поломать голову, когда вам предстоит сделать правильный выбор в зависимости от вида продукции. В этом разделе мы пробежимся по некоторым из вариантов. Несомненно, вам будет это на руку, если вы в первый раз внедряете функцию электронной коммерции – ведь это все равно что ступить на необитаемый остров.

Что продаем?

Может быть, в вашем онлайн-магазине продаются товары, которые отправляются покупателю по почте или с курьером? Или, возможно, товары, которые поставляются электронно, такие как электронные книги, музыка или ПО. Также транзакциями на сайте могут быть пожертвования или подписка на сервис. Если товары скачиваемые, то подумайте над тем, как они будут доставляться клиенту после оплаты.

Как покупать?

Один ли товар будет продаваться (например, электронная книга), или посетители смогут просматривать товары и добавлять разнообразные позиции в свою корзину? Можно ли будет выбрать товар по характеристикам (например, футболку по размеру и цвету)? Нужно ли делать категоризацию товаров, чтобы упростить их поиск? Товар будет ограничиваться одной категорией или его можно будет найти в нескольких? Пригодятся ли ярлыки и ссылки среди дополнительных или связанных товаров (скажем, позволяющие владельцу продвигать аксессуары к продукции)?

Будут ли на сайте специальные предложения – «При покупке одной вещи, вторая – в подарок!», «Скидка 20 %», «Две вещи по цене одной!», «Купите Х, получите Y за полцены!»? Реализовать подобные предложения в созданной по заказу системе может быть достаточно непросто. А если вы используете коробочную CMS, то нужно знать, сможет ли она поддерживать их.

Дьявол (как и бюджет) в деталях. Из всех сайтов, над которым я работал, наиболее склонны к расширению рамок функционала онлайн-магазины. При планировании подумайте обо всех заданных выше вопросах. Конечно, есть много чего заманчивого и желание иметь как можно больше всевозможных функций велико. Но если вы создаете CMS самостоятельно и не хотите использовать коробочные решения, то лучше старайтесь разрабатывать более простые вещи. Ведь это значительно сэкономит вам время.

Рисунок 2.2. Вещь, которая, кажется простой, на самом деле может иметь ряд опций (например, футболка может быть женской или мужской и разных размеров)

Учетная запись и отслеживание заказа

У пользователей может быть опыт использования учетной записи (аккаунта) и отслеживания заказов. Возникают вопросы: обязательно ли пользователям создавать учетную запись? Смогут ли они отслеживать свои заказы и видеть их путь от «В обработке» до «Отгружено»? Аккаунт должен иметь такие основные функции управления, как восстановление забытого пароля или обновление контактных данных.

Как принимать оплату?

Вероятно, вам понадобится принимать платежи от покупателей по кредитным и дебетовым картам. Есть несколько вариантов, разных по сложности и цене. Обычно платежи обрабатываются с помощью платежной системы, аккаунта продавца и платежного шлюза и программы-посредника SaaS (программное обеспечение как услуга). Принимать платежи онлайн через платежную систему – легко. Плюсы здесь в том, что создать аккаунт несложно, а интеграция может быть различной: от простого варианта – встраивания кода кнопки на страницу, до полной интеграции с вашей системой.

На платежном рынке есть и другие игроки, но большинство из них действуют в немногих странах. Причина в том, что большая часть законов о процедуре оплаты в каждой стране имеет свою специфику. Если вы будете принимать регулярные платежи, то вам могут пригодиться Chargify и Recurly. И хотя сейчас они доступны только в США, Stripe выглядит многообещающе как метод принятия платежей онлайн.

Чтобы напрямую принимать платежи по карте, избегая посредников, вам нужно завести аккаунт онлайн-продавца. Это позволит принимать платежи по кредитке и переводить деньги на ваш банковский счет. Если у вас есть действующий банковский счет для офлайновых продаж, вероятно, вы не сможете воспользоваться им для онлайновых транзакций. Транзакции через Интернет не совсем безопасны, поэтому прежде чем начать выполнять их, свяжитесь со своим банком. Банк посоветует защитить свой платеж, в большинстве случаев через провайдера платежных сервисов PSP (payment service provider), иногда называемым платежным шлюзом.

Рисунок 2.3. – это новый игрок на рынке, предлагающий простой способ приема платежей

Но что вы точно не должны делать, так это сохранять данные кредитной карточки, чтобы позже ввести их в терминал офлайн. Это противоречит условиям коммерческого договора. Поэтому, пока банк не даст вам свое письменное согласие и вы не выполните требования PCI DSS (о них мы расскажем позже), просто не делайте этого.

 

Платежный шлюз

Платежи через шлюз позволят вам принимать оплату от клиентов по карте, проверять ее номер и состояние счета, а после этого безопасно переводить платеж в ваш банк. Взаимодействовать со шлюзом можно двумя способами:

• Через страницу платежей

Пользователь переходит с вашего сайта на защищенную страницу провайдера платежного сервиса и вводит данные карты.

• Через интеграцию по API

Пользователь вводит данные своей карточки на вашем сайте (на странице с сертификатом защиты, который поддерживает протокол SSL), и эти данные затем отправляются в шлюз. Ваш сайт в этом случае служит посредником; пользователь не в курсе, какие транзакции проводит банк, а видит их только на вашем сайте.

Преимущества интеграции платежной страницы в том, что ваш сайт вообще не имеет отношения к данным карты, поэтому вы не несете ответственность за безопасность клиента. Но есть один большой минус. Это то, что вы уже не сможете контролировать процесс оплаты, потому что на финальном этапе требуется собрать все данные и отправить их на платежный сервер. Кроме того, редко встречается возможность настроить страницу оплатыв своем фирменном стиле или даже просто вставить в нее логотип.

Необходимость уводить клиента с сайта очень беспокоит многих владельцев магазинов. Они боятся, что пользователи будут отменять транзакцию до того, как попадут на платежную страницу WorldPay или другого сервера. Но если отправлять клиентов на сайт известного банка для введения данных карты, то они будут больше доверять вам.

Скажу о себе. Когда на каком-то незнакомом сайте (например, мелкого розничного торговца) меня просят ввести данные моей карты, я начинаю нервничать и думать, а что с ними будут делать? Высветится номер моей карты в открытом виде на экране? Сохранятся ли ее данные в базе на сервере сайта?

Даже если страница имеет сертификат защиты и подтверждения о безопасности передаваемых данных, я все равно не имею понятия, что будет с моими данными, когда я кликну «Подтвердить». Но если в финале я окажусь на знакомой странице PSP, то буду спокоен за безопасность своих данных и за то, что они не попадут на сомнительный сайт. Я больше доверяю WorldPay, чем заурядному магазину виджетов.

Еще один плюс платежной страницы в том, что, если правила оплаты по карте изменяются, они будут обрабатываться на стороне провайдера PSP. Например, один из наших клиентов требовал 3D-Secure (на такой основаны технологии Verified by Visa и MasterCard SecureCode), чтобы принимать платежи Maestro. 3D защита требует от пользователей подтверждать платеж на странице своего банка, прежде чем он будет разрешен.

Если бы мы использовали API, нам нужно было бы изменить код, чтобы интегрировать 3D защиту. Но так как мы пользовались платежной страницей, мы просто уведомляли PSP, которая включала эту функцию для нашего аккаунта.

Все эти моменты подтолкнули владельцев многих сайтов к использованию платежных страниц. Они поняли, что нести ответственность за данные кредиток – только лишняя головная боль. Платежные страницы интегрируются со многими коробочными системами. После того как платеж сделан, пользователь перенаправляется обратно на ваш сайт, а специальный код позволяет идентифицировать пользователя и транзакцию и обрабатывать необходимые данные о совершенном заказе (например, поставить в базе данных отметку «Оплачено» или обеспечить клиенту доступ к цифровой продукции).

Преимущество полной интеграции API в том, что вы можете контролировать процесс оплаты от начала до конца, в том числе оформлять страницы оплаты в своем стиле. Но вы также несете ответственность за безопасность данных пользовательских карт, и правила требуют, чтобы вы подтвердили, что используете передовые технологии.

 

PCI DSS

Стандарт безопасности данных индустрии платежных карт (The Payment Card Industry Data Security Standard (PCI DSS)) представляет собой совокупность 12 детализированных требований, которые распространяются на все компании, принимающие оплату по картам. Это относится не только к транзакциям онлайн. Обычный офлайновый магазин, который принимает платежи онлайн, должен тоже подчиняться требованиям PCI DSS для обоих способов оплаты: офлайн и онлайн.

Если вы принимаете онлайн-платежи через платежную страницу, но не получаете, обрабатываете или храните данные по картам, то вы можете заполнить сокращенный PCI DSS опросник (SAQ A), чтобы подтвердить, что ваш PSP совместим с PCI DSS. Если как средство интеграции вы используете API, то он полностью должен соответствовать PCI DSS (даже если вы не сохраняете данные карты) и включать ежеквартальные проверки безопасности, подтверждающих постоянное соблюдение требований.

В данном разделе мы не рассматриваем детали совместимости с PCI DSS, но если вы занимаетесь разработкой сайта, на котором платежи принимаются не через платежную страницу, тогда ознакомьтесь с ними или воспользуйтесь услугами тех, кто разбирается в данной теме.

Хранение данных карты

Я настоятельно советую вам не хранить данные карты на сервере клиента, даже в зашифрованном виде. Хранение данных требует совместимости с PCI DSS и поддержки сервера, а также Сети, в которых эти данные будут находиться в безопасности.

Если вам будет нужен доступ к ним, чтобы списать абонентскую плату, например вы можете поискать платежный шлюз, который предлагает сервис хранения данных. Если же вы собираетесь сохранять данные карты только для использования оплаты в один клик (как это делает Amazon), будьте осторожны! Вы в самом деле хотите взять на себя ответственность за данные вашего клиента? Хотите иметь дело с дополнительными и текущими расходами по поддержанию совместимости?

Валюта и местные налоги

Вполне возможно, что вам придется отчитываться по местным налогам, или НДС в Европе. Конечно, достаточно сложно разобраться в том, какие налоги нужны, но вы должны быть уверены, что ваша система обработает их правильно. Например, моя компания владеет скачиваемым продуктом, мини-CMS, которая называется Perch. Наша компания зарегистрирована в Великобритании, поэтому мы должны взимать налоги с британских покупателей. Еще нам нужно взимать НДС с покупателей из Евросоюза, пока у них есть действующий регистрационный номер плательщика НДС. Если покупатели из страны, которая не входит в состав Европейского Союза, мы не должны брать с них НДС. Итак, система должна уметь подтверждать номер налогоплательщика, а также правильно рассчитывать цены с или без НДС.

Большинство магазинов принимают оплату в одной валюте. Для того чтобы принимать платежи в разных валютах, чтобы посетители могли выбирать нужную им, смотреть соответствующие цены и вносить оплату, вам понадобится ввести нужную валюту в свой аккаунт продавца.

Рисунок 2.4. Платежная страница сайта. Включает НДС, скидку и приблизительную цену в долларах США. Несмотря на то что продается всего лишь один продукт, нужно принимать во внимание несколько величин

Другой вариант – это показывать цены в разных валютах, а оплату принимать только в местной. Вы можете обновлять курсы валют либо вручную, либо автоматизировать процесс с API. Если покупатели платят только местной валютой, то они должны быть в курсе, что стоимость показана чисто для информации и что реальная цена может слегка отличаться (из-за неустойчивых валютных курсов).

Обязательно посоветуйтесь с бухгалтером, когда будете иметь дело с деньгами, особенно, если вы принимаете платежи в иностранной или разной валюте. Если с самого начала знать, как обращаться с платежами и валютными курсами, то в будущем никаких проблем не возникнет.

 

О доставке

Если вы продаете физический товар, который нужно отправлять каким-то образом, вы должны включить расходы на транспортировку и, возможно, организовать отслеживание заказов. Так как вы продаете онлайн, то можно привлечь покупателей из других стран. Вам нужно решить, как рассчитать отправку в разные пункты и как вы будете доставлять товар: только в пределах вашей страны или в другие тоже.

Обычно онлайн-продавцы предлагают бесплатную доставку при заказе от определенной суммы. Также они практикуют доставку через разные службы доставки, такие как почта и курьерские службы (в зависимости от того, когда клиент хочет получить свой товар). Не забудьте учесть эти моменты, когда будете разрабатывать свой сайт.

 

Цифровые продукты

Покупатели ожидают, что они скачают цифровые продукты (такие как электронные книги, музыка и ПО) сразу же после их покупки. Доставка может быть оформлена в форме ссылки или страницы для скачивания в своем профиле (вместе с лицензионным кодом если нужно).

Система должна обезопасить продукты до их приобретения и обеспечить в аккаунте клиента область, где они будут доступны (или как минимум отправлять ссылку на e-mail). Также можно генерировать код продукта. Опять же системы-посредники могут обеспечивать весь этот функционал в рамках оплачиваемых услуг.

 

Отчет и другие функции

Ваш клиент хочет обрабатывать заказы сразу же, как только они поступят, и вероятно, отмечать отправленные позиции, как только они будут обработаны. Возможность выгружать данные по заказам в CSV-файл, будет полезна как при организации e-mail-рассылки, так и при выгрузке платежных данных в офлайновую систему учёта продаж.

Вот ряд других вопросов, которые надо задать себе или заказчику:

• Нужно ли вам контролировать остатки через сайт?

• Как вы будете поступать с заказами, которые выполнены частично?

• Должен ли сайт генерировать счета и товарные накладные или это будет происходить в офлайне?

 

Интеграция с другими системами

Многие сайты не существуют автономно, а интегрируются с другими системами и сервисами. Интеграция реквизитов доступа (т. е. логина и пароля) от сети-посредника довольно стандартная процедура, и, возможно, вам будет нужно связываться с системой-посредником для контроля остатков и учета, особенно это касается магазинов электронной коммерции.

Несколько лет назад мы разрабатывали сайт для университета, который позволял студентам и персоналу обновлять свои данные и запрашивать определенные анкеты из офиса университета. По этой причине нужно было обеспечивать логинам защиту. Для обычного сайта мы бы использовали свои собственные идентификационные классы с CMS. Но здесь нам пришлось работать с уже существующими логинами студентов. Эта информация сохранялась в LDAP (облегченный протокол службы каталогов), поэтому наш сайт должен был идентифицировать пользователей с помощью университетского сервера LDAP.

Так мы создали новый интерфейс для нашей стандартной CMS-системы, который идентифицировался через сервер LDAP. Когда работаешь с такой системой-посредником, написать код ничего не стоит.

Много времени ушло именно на то, чтобы получить доступ к серверу LDAP и понять, как подтверждается вход в систему. Мы использовали свою собственную CMS и создали идентификационный интерфейс, что упростило процесс написания кода.

В следующий раз мы разрабатывали обычную систему электронной коммерции для магазина одежды, торгующего онлайн. В нем продавались разнообразные дизайнерские модели в ограниченных количествах. Часто рубашки определенного размера и дизайна были представлены лишь в одном экземпляре. Из-за того, что рубашки продавались одновременно и в офлайн-магазинах, и онлайн, нужно было вести обновляемый учетный реестр. Если вещь продавалась онлайн, ее сразу же надо было убирать с полок обычных магазинов, а если она была куплена в обычном магазине, то информация на сайте должна была сейчас же обновляться.

Вообще, установка этой функции вызывает явные проблемы (за вещь, которую только что продали онлайн, кто-то может уже расплачиваться на кассе обычного магазина). Лучшее, что мы могли сделать, так это обеспечить одновременную двустороннюю связь между сайтом и системой электронно-кассовых продаж.

EPOS была разработана другой компанией, и нам пришлось работать с ее разработчиками, чтобы скомпоновать две системы. Мы ждали по три недели, пока эти разработчики соберут нужные ресурсы и выполнят наш запрос.

С этим мы ничего не могли поделать, и очевидно, что это время необходимо было включать в расписание проекта.

Ясность в нашем общении и представление четкой и полной информации, тестирование интерфейса, помогли свести к минимуму риск задержки. Но если вы знаете, что без посредников не обойтись, уточните, как они работают и сколько времени им нужно, чтобы обработать тот или иной запрос. Вы сможете тогда планировать свои действия с оглядкой на них.

Очень важно с самого начала узнать все о системах-посредниках, которые вам нужны. Не забывайте об этих важных задачах. Это упростит вам выбор технологии и коробочного ПО. Также это необходимо учитывать и при планировании сроков проекта как в своей компании, так и у партнеров.

 

Каждый проект имеет свои ограничения: во времени, в бюджете, в нехватке навыков и в несметном количестве других факторов. Прежде чем принять технические решения, вам нужно учесть их. Иначе эти ограничения встанут реальной преградой на вашем пути.

 

Бюджет

Когда будете планировать бюджет, учитывайте также и время. Наем разработчика или компании для создания сайта со стороны вносит ограничения в бюджет и временной график вашей работы над проектом.

Даже если посредник предлагает фиксированную сумму, она может колебаться в зависимости от того, сколько времени ему потребуется для работы. Разработка проекта своими силами также должна учитывать бюджет и время, будь то крайний срок его запуска или просто расчет времени на разработку.

Кроме чистых затрат на развитие, вам нужно будет учесть и затраты на посредников. Ведь мы все больше полагаемся на их помощь в обеспечении нашего сайта ресурсами. Хотите купить фотографии из фотобанка или шрифты? Затраты на хостинг могут увеличиться, если действующий провайдер не удовлетворяет техническим требованиям вашего нового сайта.

Если вы будете применять различные способы оплаты, то интернет-магазин понесет дополнительные затраты.

Программное обеспечение посредника может требовать оплату за лицензию, но это сократит время на разработку сайта. Вам, возможно, придется каждый месяц оплачивать услуги хост-системы. Так что включите в бюджет всевозможные затраты в начале проекта.

 

Выбор языка программирования

Возможно, ваша команда разработчиков или другое агентство по созданию сайтов имеют некий опыт в языке разработки. Он-то и определит базовый язык сайта, пока вам ужасно не захочется чего-то новенького. У хороших разработчиков всегда под рукой не один заранее заготовленный кусок кода и способы решения характерных задач на этом языке.

Но для того чтобы изменить язык на более «крутой», им потребуется серьезная переподготовка и много времени, потому что придется создавать новые библиотеки для базовых вещей. Это оправдает себя в том случае, если существующий язык мешает продвижению сайта (или из-за того, что мало кто из разработчиков знает его, или из-за того, что его развитие застопорилось). Предположим, ваша система создана на классическом ASP, и команда, которая поддерживает ее годами, знает этот язык. Однако он уже вытеснен ASP.NET (и не развивается настолько активно), поэтому строить на нем новую систему не имеет смысла. Кроме всего прочего, найти разработчиков, которые знают Classic ASP не так-то просто. Да и язык устарел настолько, что он не подходит для модернизации сайта.

Если вам придется столкнуться с подобной ситуацией, вашей команде нужно будет освоить новый язык для переделки сайта. Если агентства со стороны предлагают вам преобразование в Classic ASP, спросите их напрямую, почему они проталкивают эту технологию. Объясните им, наконец, что вы хотите сайт, который будет жить долго, а устаревшие приемы вряд ли продлят его дни.

Если вы сами создаете сайт, и вас тянет изучить определенный язык, тогда придется утрясти вопросы с отсрочкой сдачи проекта насколько это возможно. Все в ваших руках.

Постигать что-то новое всегда интересно, но не кидайтесь от одного к другому, только потому, что это модно. Лучше знать один язык, но досконально, чем несколько, но поверхностно.

Если проект готовится для заказчика, скорее всего, он станет ограничивать вас во времени и бюджете. Ограничения могут иметь под собой как техническую подоплеку (например, требование создать и разместить сайт под определенную серверную архитектуру), так и политическую (например, требование использовать ПО с открытым кодом).

 

Технические ограничения

Если компания держит свои сайты на собственных серверах, скорее всего, у нее есть своя серверная архитектура. В этом случае нужно точно знать, что вы будете устанавливать.

Например, сервер работает на Windows, а компания могла бы установить PHP; это спасло бы вас от головной боли при инсталляции, потому что есть некоторые различия между PHP на Linux и PHP на Windows (в основном если сервер работает на IIS, а не Apache).

Если организация управляет собственными серверами, тогда выясните, будет ли у вас доступ к тестированию и развертыванию приложений. В некоторых проектах у меня его не было вообще, мне приходилось паковать код и данные и отсылать их IT специалистам организации для установки. Если это ваш случай, тогда скопируйте ПО хостинга для тестирования у себя. Этим вы сэкономите себе время, потому что тестирование и изменение на рабочем сервере – процесс не из легких.

Интеграция с другой системой – своего рода ограничение. И определенные сторонние приложения могут быть исключены, если вы не можете написать плагины для их интеграции.

 

Политические ограничения

Вы можете столкнуться с ограничениями, которые продиктованы внутренней организационной политикой и предпочтениями клиента. К примеру, любое стороннее ПО должно быть с открытым кодом или использоваться должны только технологии Майкрософт.

Термин «открытый/исходный код» часто непонятен. Когда люди решают, что программное обеспечение должно быть открытым, обычно они не имеют в виду лицензию на него или бесплатное пользование. Все, что они хотят, это иметь возможность модифицировать (изменять) код, если нужно. Это позволит обезопасить себя в том случае, если разработчик стороннего продукта по каким-то причинам пропал или откажется от развития и поддержки продукта. Если от вас требуют использования ПО с открытым кодом, проясните для себя, что под этим подразумевается. Многие коммерческие продукты имеют незашифрованных и доступный для модифицирования код, но при то не имеют лицензии открытого исходного кода.

Иногда вы можете преодолеть политические ограничения, если приведете аргументы, почему какое-то решение лучше, чем то, которого от вас требуют.

Но они должны быть достаточно вескими. Ведь если клиент непоколебимо верит в какую-то технологию, то скептицизм с его стороны вам обеспечен.

 

Предположим, вы захотите заменить сервер частично или полностью. Тогда подумайте, разработать ли вам персональное решение, или положиться коробочное ПО, или, может быть, применить их комбинацию. В этом разделе мы оценим преимущества каждого варианта.

 

Зачем разрабатывать свое?

Если у вас специфичные и редкие требования, то продвижение собственной разработки может стать лучшим вариантом. Стороннее ПО должно привлекать широкий рынок, чтобы разработчики не тратили свое время зря. К тому же так заманчиво добавлять множество характеристик, чтобы платформой заинтересовалось больше народу. Вся проблема в том, что разработка системы может закончиться тем, что в ней будет сотни ненужных вам вещей.

И если движок не довести до ума, его функциональные свойства будут замедлять скорость вашего сайта, болтаться как бесполезные элементы и увеличат накладные расходы.

Если у вашего сайта большой трафик и вы с самого начала в курсе, что должны оптимизировать каждую строку серверного кода и внешнего интерфейса, то создание собственного решения позволит учесть весь список требований. Моя личная проблема в том, что я недостаточно использую язык SQL. Некоторые приложения делают сотни ненужных запросов базы данных, которые существенно повышают нагрузку на сайт.

Может случиться, что лицензия на стороннюю программу не подойдет к приложению, которое вы разрабатываете. Может быть, и так, что в системе есть все, что нужно, но какие-то 10 % функций, которые вы добавляете, требуют довольно глубокого проникновения в ядро программы, проще говоря, ее взлома. Вряд ли кто-то из разработчиков софта даст вам добро на это. Вот она и проблема! Сложность будет еще и в том, чтобы усовершенствовать программу.

Лучше делайте свои изменения через официальный API. Если не сможете, все равно не взламывайте программу. Потому что то, что у вас получится, вы едва ли сможете поддерживать.

Плюсы в разработке и развитии собственной системы в том, что вы точно сможете подогнать ее под свои требования. Стандартная программа может быть написана великолепно, и так же великолепно удовлетворять требования заказчика. Но при этом утечка конфиденциальной информации все равно возможна. А теперь ваша задача – оценить, что лучше: использование готовых программ или создание своей, точно ориентированной на ваши задачи?

 

Выбираем коробочную платформу?

Коробочное ПО имеет явные преимущества. Вам не надо начинать с чистого листа. Вы получаете то, что уже находится в боевой готовности. Если вы ищете легкий способ управления контентом или ведения онлайн-магазина, а ваши требования достаточно просты, то наверняка одно из многих существующих в программе решений удовлетворит вас.

Есть бесплатные сторонние программы, а есть лицензионные, за которые приходится платить. У некоторых бесплатный только основной продукт, а дополнения – платные. Они добавляются быстро, поэтому заранее подумайте о том, что вам нужно для проекта. В одной системе может быть все включено в лицензионную оплату. Она, несомненно, обойдется вам дешевле, чем бесплатная альтернатива, для которой нужно будет приобрести несколько коммерческих дополнений.

Не забудьте узнать, на какую поддержку вы можете рассчитывать. У многих бесплатных программ официальная поддержка стоит денег или вовсе не существует. Еще не помешает зайти на форум, где пользователи отвечают друг другу на вопросы. Посмотрите, сколько людей участвует в нем и как быстро приходят ответы.

Рисунок 2.5. На WordPress оживленные форумы. Они для людей, которым нужно помочь в выборе правильного ПО

Если поддержка включена в стоимость, узнайте, в каком виде она предоставляется. Есть ли на нее ограничения или нет? Придется ли ждать? Существует ли общественная площадка поддержки и сразу ли персонал отвечает на вопросы? Twitter, кстати, тоже неплохой способ узнать о поддержке и общественном мнении о продукте. Просто спросите о нем и посмотрите, какие отзывы вы получите. Если поддержка хорошая, платный продукт может быть более стоящим, чем бесплатный вариант.

 

Облачные решения

Третий способ решения, который нам нужно обсудить, – это программное обеспечение как услуга (SaaS), известные также как облачное ПО. Есть системы управления контентом (CMS), которые, к примеру, используются в электронной коммерции. В них реализован различный функционал, начиная от простого «положить в корзину» и страницы оплаты и заканчивая полноценным интернет-магазином. Такое решение привлекательно тем, что вам не нужно ничего устанавливать, чтобы запустить и поддерживать сайт. Может лишь возникнуть необходимость настроить некоторые опции и выбрать шаблон.

Использование внешнего размещения – быстрый способ запустить в работу ваш сайт. Вообще, в проектах электронной коммерции, такое решение перекладывает проблемы безопасности и сложных функций на компанию, которая специализируется на этом. Но есть кое-что, над чем нужно подумать.

Возможно, заказчик должен платить за пользование сервером ежемесячно и, естественно, это нужно внести в бюджет. Проверьте, изменится ли цена в зависимости от вашего трафика и количества заказов.

Вы также не можете изменять работу такого ПО. Если разработчик вносит изменения, которые влияют на ваш бизнес, придется с этим смириться. Вы не сможете переписать какую-то часть так, как вы это делаете с программой, находящейся на вашем сервере. Это и понятно. К ее исходному коду вы имеете доступ.

Ваш сайт будет зависеть от деятельности разработчиков облачного ПО, которые крутятся в бизнесе и не перестают предлагать услуги заказчикам по доступным для них ценам. Программа, установленная на вашем сервере, даже если провайдер отойдет от дел, все равно остается у вас. Правда, вы потеряете поддержку, но по крайней мере сможете перейти на что-то свое абсолютно бесплатно. Если вы будете полагаться на внешний сервер, тщательно исследуйте его, чтобы убедиться, что он надежный, а компания – стабильная.

 

Бойтесь «евангелистов»!

Пользователи определенных продуктов порой проявляют свои странности. Вы это можете наблюдать на форуме, куда они заходят и наивно спрашивают: «А какая CMS лучше?»

По большому счету это бессмысленный вопрос. Он не прольет света на проблему, которую вы стараетесь решить. Читатель понятия не имеет, какой у вас сайт: крошечный с несколькими кусочками редактируемого текста или огромный трехъязычный, вмещающий в себя тысячи документов.

И все равно кто-нибудь да расскажет вам о своей любимой CMS и в восторге станет доказывать, почему она лучшая из лучших. Этих людей мы называем «евангелистами»: они так любят софт, которым пользуются, что и представить себе не могут, что у кого-то может быть что-то другое. Я сам являюсь поставщиком CMS. Именно поэтому я иногда имею свою выгоду от «евангелистов» в среде наших пользователей. Но я и первый, кто в случае, если наше решение не вписывается в проект, скажет об этом прямо.

Бойтесь «евангелистов», когда вы изучаете стороннее ПО. Неважно, что это будет: целая платформа или простой скрипт. Задавайте специфические вопросы с учетом ваших требований. Тогда, скорее всего, в ответ вы получите более квалифицированное мнение.

 

Нас часто просят порекомендовать хороших хостинг-провайдеров и помочь с выбором хоста. Хостеров тысячи, но все они предлагают в конечном итоге серверы, которые могут мало отличаться друг от друга внешне, но по стоимости – в разы. Так что же выбрать? Может быть, просто хостера подешевле, у которого есть все, что вам нужно?

 

Дешевый хостинг – дорогой хостинг, или Скупой платит дважды

Многим хостинг-провайдерам удается сбывать свой продукт на рынке чисто из-за низкой стоимости. Можно достать хостинг за $10 в год. Но то, что есть такой дешевый хостинг, еще не говорит о том, что надо пользоваться им. Он может в результате обойтись вам гораздо дороже, чем качественный хостинг с разумной, обоснованной ценой. Хороший хост стоит денег. А если заказчик толкает вас к дешевому провайдеру, то, надеюсь, что, прочитав этот раздел, вы вооружитесь неплохими контраргументами.

Веб-хост с оплатой $10 в год, чтобы «сколотить» хоть какие-то деньги, должен разместить сотни сайтов на каждый физический сервер. Соответственно, это может привести к перегрузке, и какой-нибудь сайт с тяжелым трафиком застопорит остальные или даже выведет их в офлайн.

Google сейчас использует показатель скорости загрузки сайта для ранжирования выдачи, таким образом, медленный сайт не только раздражает пользователей, но и ухудшает позицию выдачи.

Рассчитывать на техническую поддержку за $10 в год было бы глупо. Ни один провайдер не сможет этого сделать за такие деньги. Если ваш сайт стал хуже работать и проблема коснулась пользователей, знайте, что вы можете быстро связаться со специалистом в приоритетном порядке. Услуги клиентам стоят денег. Так что низкая цена хостинга окупается за счет платы за поддержку.

 

Как выбрать хост

Ваш сайт имеет определенные требования. Например, чтобы запустить сайт на WordPress, вам нужен следующий набор:

• PHP версии 5.2.4 или выше,

• MySQL версии 5.0.15 или выше,

• модуль Apachemod_rewrite.

Рисунок 2.6. Проверьте последнюю стабильную версию PHP на php.net

Если вы используете серверный язык и базу данных, убедитесь, что ваш хост поддерживает их, а также и минимальную версию, которую требует ПО. Правило номер один: держитесь подальше от хостов со старыми версиями серверных языков. Вы можете ознакомиться с современной версией PHP на сайте php.net, проверив раздел «Стабильный релиз». На момент написания последняя версия – 5.3.9. Если хост поддерживает обновления, то его версия – 5.3, естественно, версии продукта не должны быть моложе, чем 5.2.4, как требуется для WordPress.

Хост может поддерживать серверы со старыми версиями PHP, если нужна поддержка пользователей, работающих на них. Но он должен быть в состоянии также их обновлять их по требованию или создавать новые аккаунты (учетные записи) для новых серверов.

Базы данных

Если вам нужна база данных для сайта (например, контент блога WordPress хранится в базе данных MySQL), посмотрите, предоставляет ли хост хотя бы одну. Если у вас свои скрипты, то внедрить каждый с собственной базой данных, возможно, будет легче. Поэтому проверьте, какое количество баз допустимо. Что касается скриптового языка сервера, выясните, совместима или нет версия базы данных того софта, который предлагает хост, с вашими скриптами.

Вам нужна поддержка e-mail-сервера?

Если вы хотите использовать один и тот же сервер как для e-mail, так и хостинга, узнайте, что он предлагает. Есть ли у него нужный вам web-mail? Сможете ли вы использовать e-mail с протоколами POP или IMAP? Легко ли использовать интерфейс для установки почтовых сообщений? Есть ли антиспам-фильтр?

Нужно ли вам размещать несколько доменов на одном сайте?

Некоторые хостинговые компании разрешают регистрацию только одного домена на вашем сайте. Если вы собираетесь завести несколько доменов, разведайте, возможно ли это вообще.

 

Принимаем решение

Существует тысячи хостинговых компаний. Выбирайте, но с умом! Ведь если вы подберете ненадежного хостера, последствия могут быть весьма серьезными для той компании, чей сайт является «сердцем» ее бизнеса. Так как же выбрать надежный хост?

Хорошим признаком служат рекомендации. Они очень действенны, особенно если человек, который их дает, пользуется хостингом не один год. Когда вы сотрудничаете с разработчиками сайтов, возможно, что они посоветуют надежного провайдера, с которым работали, и скажут, от кого надо бежать как черт от ладана!

Стоит поискать хостеров на Google. Если у людей были с кем-то из них проблемы, они сообщат об этом на форумах или в блогах. Если увидите много плохих отзывов о какой-то компании, держитесь от нее подальше. Еще один неплохой способ получения информации – это Twitter. В сущности, люди любят «пощебетать» о своих проблемах в реальном времени, даже если они не склонны расписывать их на форумах и в блогах.

Как я уже говорил, достать очень дешевый хостинг – не проблема. Прекрасно, когда сайт ваш личный или создается для друзей. Но если же он крайне важен для вас и для бизнеса заказчика, тогда помните, за что платите – то и получаете. Если хотите быстро справляться с проблемами, стоит заплатить немного больше.

Узнайте, как провайдер предоставляет поддержку. У некоторых хостов она осуществляется только через электронную почту, и это может быть для кого-то достаточным. Но ваш заказчик, возможно, захочет такого провайдера, которому он сможет позвонить, когда их почтовый сервер или сайт «упадет». Если вы знаете кого-нибудь, кто пользуется провайдером, который вы рассматриваете как вариант, узнайте, приходилось ли этим людям обращаться к нему за поддержкой и каков был опыт.

Как мы уже говорили, языки сервера нужно обновлять в целях безопасности и совместимости, как и настольные компьютеры. Если хостинг поддерживает очень старую версию языка, это говорит о том, что его серверы не современные. А это значит, что они уязвимы. Вы должны вникнуть в эти проблемы и попытаться установить скрипт с открытым кодом, который основан на современной версии языка программирования. Многие провайдеры дают гарантию на время работы, обычно в процентах: «Стопроцентная гарантия на время работы». Имеется в виду, что ваш сайт будет функционировать на 100 % в течение всего времени работы. Но не обольщайтесь и не рассчитывайте на многое!

Хостер обычно выплачивает компенсацию в случае, если сайт недоступен больше гарантированного времени, но вы сами должны контролировать такие моменты и предупреждать хостера перед тем как работа сайта будет восстановлена. Нет ничего приятного, если ваш сайт вдруг в 2 часа ночи перестал работать. Также гарантия доступного времени работы распространяется на сам сервер, но не на каналы связи.

Когда я выбираю хостинг, я мало обращаю внимания на заверения о времени доступности серверов по словам самого хостера, я спрашиваю пользователей этого хостера об этом и о работе техподдержки. Будьте осторожны! Не нарвитесь на хостинг компании, которая занимается перепродажей серверов крупных поставщиков. Любой может купить сервер у крупного хостера и начать распродавать его дисковое пространство, при этом не имея малейшего представления о хостинге вообще. В этом случае, если ваш сайт упадет, вы столкнетесь с тем, что это посредник не в силах ничего с этим сделать. Он лишь может посоветовать вам обратиться напрямую к хостеру. С посредником, который болтался между вами и теми, кто действительно решит ваши проблемы, будет покончено.

Рисунок 2.7. Хостинг компания Memset предлагает ряд личных (приватных) виртуальных серверных пакетов

 

Типы хостинга

Много лет виртуальный (разделяемый) хостинг считался единственно прибыльным способом объединять почти все большие сайты. Сайт на виртуальном хостинге разделяет сервер с сотнями других. Вам будет выделено свое ограниченное пространство, поэтому вы не сможете конфигурировать или устанавливать софт на сервер.

Как альтернативу виртуальному можно привести выделенный сервер – физический компьютер, который вы получите целиком. С ним вам будет намного проще, потому что вы сможете изменять его установки, а также его «родной» софт. Но это удовольствие не из дешевых, именно поэтому многим сайтам не нужны пространство и ресурсы выделенного сервера.

В последние годы появился новый вид хостинга. Называется он «виртуальный выделенный сервер». В плане управления операционной системой он соответствует выделенному серверу, но по факту вы делите один физический сервер с другими виртуальными. Плюсы такого виртуального хостинга в том, что вы можете работать с какой угодно версией операционной системы и ПО, которое вам по душе.

А это значит, что вы можете изменять сервер и устанавливать на нем сложные сайты.

Многие компании, предлагающие этот вид хостинга, по умолчанию прилагают панель управления, чтобы облегчить людям работу на сервере, в том числе и тем, кто никогда не администрировал такую систему раньше.

Две наиболее известные панели – это Plesk и cPanel (которые включают панель Web Host Manager). С помощью этих средств вы сможете установить новый сайт на сервере и актуализировать обновления, а также компоновать сервисы, доступные для индивидуальных сайтов. В сущности, имея виртуальный выделенный сервис, вы сами себе хозяева.

Виртуальные выделенные серверы также удобны для настройки показа сайта заказчикам, возможно на субдомене. Для дизайнеров, чье кредо – не передавать файлы до тех пор, пока заказчик не оплатит их, такая настройка позволит предоставить на утверждение сайт полностью, прежде чем отправить его клиенту.

Виртуальный выделенный сервер дает компаниям максимальную гибкость. Но если у вас неспецифические требования, то для их выполнения, скорее всего, подойдет стандартный общий пакет хостинговых услуг. Он имеет соответствующие спецификации и надежную поддержку, а также постоянно обновляется.

Облачный хостинг отличается от виртуального и виртуально-выделенного. В нем ресурсы, необходимые для вашего сайта, могут быть разбросаны по другим серверам, и вы вольны в том, чтобы добавлять их или, если нужно, убирать. Этот вид хостинга подходит для приложений, которым иногда требуются мощные ресурсы, а иногда – низкие.

Хороший тому пример – продажа билетов. Наплыв пользователей на сайт наблюдается, когда в продажу выбрасывают билеты на какое-то популярное событие, но все остальное время трафик остается низким. С облачным хостингом у вас будет, когда нужно, доступ к дополнительным мощностям (конечно же, не бесплатно), а резервная мощность сохраняется круглый год.

 

Данный раздел больше подойдет не тем разработчикам, которые работают в большой команде, а для дизайнеров, которые впервые взялись за полную переделку сайта. Мы поделимся своим опытом, а затем займемся непосредственно переделкой.

Неважно, переделываете ли вы работающий в данный момент сайт или просто дополняете его новыми элементами или интерфейсом, это не должно навредить пользователям. Даже если изменения ничтожны, никогда не обновляйте сайт, пока не протестируйте изменения.

Один из методов, у которого много поклонников, это вести разработку, добавляя подпапки на существующем сайте. Не самая хорошая идея, однако! Когда вы будете готовы к запуску сайта и перенесете новые файлы выше, в корневой раздел сайта, относительные ссылки станут неверными. Все изображения могут «слететь» из-за этого. Придется вам тогда все восстанавливать. Согласитесь, не лучшее начало проекта!

Для разработки лучше настроить локальное оборудование, включая серверные скрипты и правильные пути к корню. Затем загрузите его на вспомогательный сервер, где вы будете проверять сайт на вебе, показывать его заказчику, наполнять контент и получать добро на дальнейшее существование.

Если вы дорабатываете «живущий» сайт или перекраиваете интерфейс пользователя, а код оставляете более или менее нетронутым, мой вам совет: экспортируйте базу данных и скачайте все файлы (об этом прочтете позже в статье «Перенос вашего сайта»). Это нужно для того чтобы настроить разрабатываемую и промежуточную версии сайта в точности, как на действующем сайте. Если база данных с рабочего сайта содержит конфиденциальную информацию о пользователях, лучше использовать псевдозаполнение данных. Не только для того чтобы защитить данные, но и во избежание их случайной отправки 10 000 пользователям из вашей локальной системы, когда будете что-то проверять!

 

Вспомогательный сервер

Локальный сервер устанавливается на ваш собственный компьютер или какой-то другой у вас в офисе, и вы используете его для разработки сайта. Когда будете готовы показать заказчику свою работу, вам придется переместить его куда-то, где к нему будет доступ с других сетей. «Куда-то» означает перемещение на вспомогательный сервер.

Он так же прост, как и поддомен, который указывает папку на вашем текущем сервере. Это позволит вам протестировать сайт на реальном сервере с заданной конфигурацией и всеми корректными путями.

Если вы создаете большое количество сайтов для заказчиков и собираетесь использовать те же настройки сервера (тот же язык, базы данных и проч.), вы можете взять дешевый виртуальный выделенный сервер и задать для каждого клиентского сайта свой субдомен для тестирования.

В этом случае желательно обезопасить директорию. Чтобы зайти на сайт, посетители должны будут ввести пароль. Это помешает случайным людям увидеть вашу «сырую» разработку и спасет от индексирования этого сайта Google.

При разработке сайтов со сложной структурой и разным контентом для заказчиков, мы обеспечиваем им доступ к его промежуточной версии, где они смогут добавить свой контент и тщательно изучить сайт. Потом мы перемещаем сайт, базу данных и прочие необходимые объекты на текущий сервер, что обеспечивает быструю и легкую миграцию новой версии сайта без ошибок.

 

Контроль версий

Мы не можем говорить о среде разработки, не упомянув о контроле версий. Даже если вы работаете в одиночку, вы должны его использовать. И это всегда полезно для тех, кто работает в команде. Ее члены смогут править файлы и не волноваться о том, что они «затирают» файлы друг друга. Вы всегда сможете вернуться к прежней версии, если что-то пойдет не так.

Если вы решили доработать сайт, а не переделать его полностью, ваш первый шаг – это импортирование всех файлов в одну из систем контроля версий. Так вы всегда сможете откатиться назад, если какие-то изменения чисто случайно затронут часть системы.

Даже когда вы работаете один, управление версиями защищает вас от самого себя. Например, от случайного удаления файла или быстрого изменения приложения. Я использую управление версиями, чтобы переносить работу с компьютера на компьютер, если это нужно. В конце каждого дня я фиксирую свою работу. Если моя дочь не пошла в школу и я работаю на дому, я могу взять текущие файлы и начать точно с того места, на котором я остановился позавчера вечером в офисе.

Рисунок 2.8. Beanstalk сервис для контроля версий

Существует несколько систем управления версиями. Вы, наверное, слышали о таких, как Subversion и Git. Обычно каждый выбирает, кому что нравится. Так как для выполнения работы вы можете менять сервер, то используя такие веб-сервисы, как GitHub или Beanstalk, вы можете быстро приступать к работе. Beanstalk имеет отличное руководство по управлению версиями на своем сайте.

 

Вопрос, как переместить сайт с одного сервера на другой, мучает многих, особенно если сайт пользуется популярностью. Но если вы будете следовать рекомендациям ниже, то увидите, что сделать это возможно и без явного ущерба для посетителей. Этот процесс аналогичен переносу сайта с промежуточного сервера на основной.

Инструкции, данные ниже, предназначены для развертывания сайта на оборудовании обычного виртуального хостинга, с SFTP доступом. Если ваше оборудование сложнее, чем это, тогда у вас, вероятно, уже есть специалист, который поможет вам разобраться.

 

Установка нового оборудования хостинга

Для начала вы должны настроить хостинг. Проверьте, есть ли в нем все необходимые возможности, включая поддержку нужного вам серверного языка и базы данных.

 

Перемещение файлов на новый сервер

Для загрузки файлов сайта на новый сервер используйте SFTP. Новый сервер может предоставлять вам временный домен для тестирования сайта. Если нет, то я обычно временно создаю на сервере поддомен, пока я проверяю, все ли работает как надо.

Избегайте предварительного просмотра сайта с тильдой (~) или с вашим именем пользователя, иначе пути и ссылки побьются.

 

Перенос базы данных на новый сервер

Если вы работаете на приложениях не от Microsoft, то, скорее всего, вы используете MySQL. MySQL – это база данных, используемая для большинства приложений с открытыми «исходниками». Ее любят разработчики, которые работают с PHP, Python и Ruby on Rails.

Первое, что вы должны знать при работе с такой базой данных, как MySQL, это то, что в ней нет файла данных для скачивания и пересылки. База хранится внутри MySQL сервера. Чтобы получить данные, вам надо будет подключиться к нему. Многие серверы устанавливаются с PHPMyAdmin – веб-приложением, которое позволяет управлять базами данных через браузер.

Вы также сами можете загрузить и установить PHPMyAdmin. С ним вам будет удобно переносить базу данных MySQL между локальным, вспомогательным и рабочим серверами.

 

Настройка почтовых ящиков

Если ваша почта будет располагаться на новом домене, тогда установите почтовые учетные записи так, чтобы они были готовы к использованию, как только домен будет прикреплен к новому серверу.

 

Изменение сервера доменных имен, или переназначение записи домена

Если вы изменяете DNS домена на ваш новый сервер, то нужно изменить и серверы доменных имен. Если ваш DNS расположен где-то в другом месте, а вам нужно изменить запись так, чтобы домен указывал на новый сервер, то измените лишь запись A. На это уйдет какое-то время. Пока новая запись между доменом и сервером не будет прописана по всему Интернету, продолжайте проверять почту со старого сервера день-другой, чтобы быть уверенным, что вы не потеряли ничего важного. Если прежний хост позволяет пользователям проверять почту в веб-интерфейсе без захода на домен, делайте так, пока почта не перестанет проходить через него.

 

Перенос сайта, работающего на базе данных

Для перемещения сайта, работающего на базе данных, нужно время: во-первых, чтобы запись DNS обновилась по всему Интернету, и во-вторых, для обновления кэширующих серверов. В течение этого промежутка времени, одни посетители могут направляться на старый хост, а другие – на новый. Если ваша база данных предназначена только для внутреннего управления контентом, и посетители не могут добавлять его, тогда просто попросите контент-менеджеров не изменять информацию на сайте до тех пор, пока они не будут уверены, что теперь они работают с сайтом на новом сервере.

В этом случае я проверяю сайт на копии базы данных и затем перемещаю базу непосредственно перед сменой доменных имен. Мне надо точно знать, что я перенес большую часть обновленного контента. Если посетители добавляют данные в базу (например, они делают заказы в онлайн-магазине), тогда вам ни в коем случае нельзя терять их при перемещении. Самый надежный способ – временно выключить сайт и разместить на нем страницу, с уведомлением, что идут технические работы.

Если так не получается, есть пара обходных маневров. Во-первых, сделайте перенос, как описано выше, а когда убедитесь, что DNS полностью переключился, сравните две базы данных и синхронизируйте записи от старых к новым. Если у сайта очень низкий трафик, а вы ожидаете только пару заказов или комментариев за это время, это сработает. Как вариант, вы можете сначала переместить базу данных. Пока будет настраиваться новый хостинг, чтобы внешний сайт мог соединиться с базой данных, вы можете переместить ее, а затем присоединить и старый, и новый сайты к базе данных в новых настройках сервера.

Если это ваш случай, то попросите вашего хостинг-провайдера (и разработчика, если он у вас есть) сделать все лучшим образом.