Какие гарантии Вы используете, чтобы не случайно вносить непреднамеренные изменения в Вашу продуктивную среду?
Вы можете получить название дженериков из подкласса. Смотрите этот пример. Определим родительский класс следующим образом:
public class GetTypeParent<T> {
protected String getGenericName()
{
return ((Class<T>) ((ParameterizedType) getClass()
.getGenericSuperclass()).getActualTypeArguments()[0]).getTypeName();
}
}
Затем мы определим его дочерний класс следующим образом:
public class GetTypeChild extends GetTypeParent<Integer> {
public static void main(String[] args) {
GetTypeChild getTypeChild = new GetTypeChild();
System.out.println(getTypeChild.getGenericName());
}
}
Это можно увидеть в методе main или в любом методе экземпляра. , Я могу получить имя типа generics, в этом случае основной выводит: java.lang.Integer .
10 ответов
Новые производственные выпуски проходят через наших системных ребят, программисты и разработчики могут только запрашивать запуск их новой системы, требуется также одобрение, и мы показываем, что каждое внесенное изменение было протестировано (путем включения снимка всего, что было протестировано в этом выпуске, в производственный запрос).
Мы сохраняем предыдущие производственные выпуски для отката в случае возникновения проблем.
Если что-то сломается (что не должно происходить часто при правильной процедуре тестирования и управляемых выпусках), мы можем либо откатиться, либо исправить. Часто, когда что-то ломается в реальном времени и исправление невелико, мы можем исправить, а затем перенести исправление в тест, чтобы провести надлежащий тест.
Тем не менее, иногда все проходит ...
система управления версиями. нет ничего лучше отката, когда дела идут непоправимо неправильно. Кроме того, разница может помочь вам воспроизвести изменения в других производственных системах.
разрешает доступ на запись только определенным учетным записям, поэтому вам необходимо войти в систему по-разному, чтобы внести изменения
на веб-сервере, иметь две структуры каталогов, которые зеркально отражают друг друга, в одной только один идентификатор может писать, другой промежуточный каталог, каждый может писать.
на сервере базы данных, иметь одну производственную базу данных, в которую может писать только один идентификатор, иметь промежуточную базу данных, в которую каждый может писать. для промежуточной БД может быть восстановлена ночная резервная копия.
ОДНАКО, если у вас есть неправильный запрос или некоторая перегрузка ресурсов в вашей промежуточной системе, ресурсы будут извлечены из рабочей среды, и машина может зависнуть.
Для веб-серверов и серверов приложений я бы попытался скопировать среду в новое место (но в той же среде) и попросить затронутых людей воспроизвести поведение копии. Это, по крайней мере, даст вам определенную степень защиты от случайного облаживания 100% ваших клиентов.
Для серверов баз данных я бы настроил учетные записи пользователей в производственной системе, чтобы дать им права только для чтения.
Учетные записи только для чтения / гостевые учетные записи. Шутки в сторону. По этой же причине вы не всегда входите в систему как root или администратор.
Это сложная вещь, и она идет с территорией «без промежуточной среды».
По многим причинам лучше иметь выделенный (дубликат) PROD, который вы можете использовать для этапов развертывания ... и для отладки, но я знаю, что иногда, когда вы начинаете, это не срабатывает так быстро и тщательно, как хотелось бы.
Одна вещь, которую я видел как работает, это использование виртуальных машин: помимо среды отладки, вы можете создать мини-PROD в виртуальной машине и использовать его для отладки. Это может оказаться непрактичным, учитывая тип разрабатываемого вами приложения, поэтому дополнительные детали в этой области были бы полезны.
Что касается того, чтобы избежать изменений PROD во время отладки: есть ли причина, по которой вам нужно что-либо изменить, чтобы облегчить отладка? Если так, возможно, стоит поискать другой способ решения проблемы.
Извините, у вас должна быть промежуточная среда. От этого никуда не деться. Если это означает, что вам нужно отсеять размер ваших наборов данных, то это то, что вам нужно сделать. Используйте VMware и VMware converter для импорта производственных систем в периоды простоя, если они у вас есть (это многочасовой процесс, поэтому, возможно, это непрактично).
Есть определенный класс проблем, которые нельзя решить, не имея полного доступа к производственным базам данных (или их копии), производительность - одна из них. Но вам действительно следует создать промежуточную среду, даже если она находится на чьем-то настольном компьютере с урезанным набором данных.
Кроме того, мне приходилось прожить свою жизнь с некоторыми из них в прошлом, и на самом деле ничего нет вы можете делать, кроме множества резервных копий. Каждому вносимому вами изменению должно предшествовать инкрементное резервное копирование. Таким образом, если вы что-то сделали, сумма, которую вы потеряли, будет незначительной. SQL-сервер может выполнять дифференциальные резервные копии, которые ограничивают объем дискового пространства, используемого для резервного копирования. Oracle тоже может.
Контроль версий чрезвычайно полезен для управления изменениями в производственной среде - просто сделайте свою производственную среду рабочей копией соответствующего каталога или каталогов из репозитория. Когда вы запускаете обновление, ваша система контроля версий гарантирует, что ВСЕ измененные файлы будут скопированы. Когда обновление что-то ломает, вы можете откатить рабочую копию до последней ревизии, которая не была повреждена. Кроме того, вы можете проверить свой рабочий туалет по тегу, а не из ствола; таким образом вы можете решить, какие ревизии репозитория применить к производственной среде, настроив тег.
Если вы не знакомы с концепциями систем контроля версий, я бы посоветовал вам провести небольшое исследование. Они концептуально сложны, но невероятно полезны и мощны. http://en.wikipedia.org/wiki/Revision_control
Если у вас действительно нет другого выбора, и это, вероятно, будет хроническая ситуация ... рассмотрите возможность добавления какого-либо способа к данным приложения (файлам или базе данных), чтобы отметить набор данные в виде «пожалуйста, боже, на самом деле не меняйте состояние производства с помощью этих данных», в сочетании с дампами данных в критических точках процесса, когда этот флаг активирован, вы можете использовать большую часть производственной логики без фактического выполнения данных на.