Вопросы Теги

Ежедневные сборки, который реалистичен?

Делегирование события

Привязка / регистрация предка для события

Динамически добавленные теги не могут привязываться к обработчику / прослушивателю событий, только теги, которые существовали со страницы был загружен может. Таким образом, для нескольких динамически добавляемых тегов, таких как кнопки, вы должны найти тег-предок, к которому они все имеют общий доступ, и связать его с любым событием, которое вам нужно прослушать. Для ваших кнопок это может быть ближайший предок table * (рекомендуется), самый дальний window: 

// On-event property. ALWAYS PASS THE EVENT OBJECT 
table.onclick = function(event) {...
blockquote>

ИЛИ [ 1139] 

// Event Listener. Abbreviating the [Event Object][2] is OK, but you must be consistent.
table.addEventListener('click', function(e) {...
blockquote>

Не использовать атрибуты по событию

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

Использование Event.target и Event.currentTarget Свойства

Не забудьте передать объект события, потому что он понадобится вам ...

  • ... выяснить, на какую кнопку вы действительно нажали с помощью свойства event.target.

  • ... получить ссылку на таблицу со свойством event.currentTarget.

  • ... возможно, предотвратить поведение по умолчанию, такое как остановка отправки формы на сервер с помощью метода event.preventDefault() .

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

Демо

Подробности прокомментированы в демо 

var table = document.querySelector("table");

document.forms[0].onsubmit = fillData;

/*
This onevent property handler has two functions note it is bound 
to the table NOT the buttons.
There's two conditionals and they only focus on classNames of 
either .del or .edit. Once it's determined if the clicked tag has
one of these classes then the appropriate function is called.
If neither class was clicked there's no opportunity for anything
else to act on the click because both conditionals end with 
return false thereby terminating the event handler.
*/
table.onclick = function(e) {
  if (e.target.className === 'del') {
    delRow(e);
    return false;
  }
  if (e.target.className === 'edit') {
    editRow(e);
    return false;
  }
};

function fillData(e) {
  var ui = e.target.elements;
  e.preventDefault();
  var idx = table.rows.length;
  var row = table.insertRow();
  row.id = 'r-' + idx;

  var cell1 = row.insertCell(0);
  var data1 = ui.title.value;
  cell1.textContent = data1;

  var cell2 = row.insertCell(1);
  var data2 = ui.desc.value;
  cell2.textContent = data2;

  var cell3 = row.insertCell(2);
  var data3 = ui.chk.checked ? 'Active' : 'Inactive';
  cell3.textContent = data3;

  var cell4 = row.insertCell(3);
  var btns = `
  
  `;
  cell4.innerHTML = btns;
}

/*
Reference the .closest() row from clicked button
Get that row's id and split() it at the dash and pop() the number.
Then get a reference to the bound ancestor (table) and deleteRow() with the new number you just got.
*/
function delRow(e) {
  var row = e.target.closest('tr');
  var idx = row.id.split('-').pop();
  e.currentTarget.deleteRow(idx);
}

/*
Same as before get the index number from the closest row's id.
Reference the table and use the .rows property and number.
This reference will now allow you to use the .cells property.
Use the .cells property to toggle the contenteditable attribute
on the first three cells.
*/
function editRow(e) {
  var row = e.target.closest('tr');
  var idx = row.id.split('-').pop();
  var R = e.currentTarget.rows[idx];
  for (let c = 0; c < 3; c++) {
    var cell = R.cells[c];
    if (cell.hasAttribute('contenteditable')) {
      cell.removeAttribute('contenteditable');
    } else {
      cell.setAttribute('contenteditable', true);
    }
  }
}
body {
  font: 400 16px/25px Consolas;
  display: flex;
  justify-content: space-between;
}

fieldset {
  width: fit-content
}

input,
label,
textarea {
  font: inherit
}

input,
label,
button {
  display: inline-block;
  height: 25px;
}

#title {
  width: 27.5ch;
}

#chk {
  display: none;
}

#chk+label::after {
  content: '\2610';
  font-size: 20px;
  vertical-align: middle;
}

#chk:checked+label::after {
  content: '\2611';
}

[type='reset'] {
  margin-left: 5%
}

td {
  min-width: 60px;
  border-bottom: 1px solid #000;
  height: 25px;
}

tr td:last-child {
  border-bottom-color: transparent;
}

button {
  width: 35px;
  text-align: center;
}

  

    Enter Data
8
задан M4N 4 January 2009 в 22:10
поделиться

10 ответов

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

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

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

10
ответ дан 5 December 2019 в 05:08
поделиться

В магазине с 1 человеком или даже (особенно) более крупных магазинах, как в мире можно поддержать ежедневную сборку?

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

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

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

Легкий, только основывайтесь на репозитории. Только проверьте материал в репозитории, который работает.

Действительно ли это - цель разработки гарантировать работы сборки через каждое изменение?

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

8
ответ дан 5 December 2019 в 05:08
поделиться

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

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

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

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

Затем можно объединить изменения от ответвления разработки до основного ответвления.

4
ответ дан 5 December 2019 в 05:08
поделиться

Я использовал CruiseControl для реализации, Продолжает Интеграцию, которая даже создает новые сборки и развертывает их на каждой регистрации SVN, таким образом, ответ на тот вопрос является категорическим ДА... ;)

4
ответ дан 5 December 2019 в 05:08
поделиться

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

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

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

1
ответ дан 5 December 2019 в 05:08
поделиться

В коротком...

Автоматизировать.

Не регистрируйте его, пока это не будет сделано.

Да.

1
ответ дан 5 December 2019 в 05:08
поделиться

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

Имейте поток разработки, QA (или тест) поток и наконец поток выпуска.

Создайте свой QA и выпустите потоки каждый раз, когда они изменяются. Создайте свой поток разработки только, когда Вы должны будете.

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

1
ответ дан 5 December 2019 в 05:08
поделиться

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

На всех моих проектах мы делаем ПОЧАСОВЫЕ сборки. Мы используем Luntbuild, чтобы сделать это, и он отправит всем участникам проекта по почте, как только сборка перестала работать и продолжит отправлять по почте до работ сборки. Взломанный код не становится зарегистрированным, и когда кто-то повреждает сборку, он должен получить cookie для целой команды (или другое подходящее "унижение" :-)).

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

Вы будете видеть, что это приведет к лучшему коду и shippable проекту почти в любое время во время проекта потому что:

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

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

Мой текущий проект имеет 2 проблемы, один являющийся, который buildserver не отправляет по почте из-за сетевой проблемы и другого существа, что существует слишком много паники. Это означает, что сбой, почасовые сборки замечены намного позже, и еженедельные установки, не возможен из-за незаконченной функциональности. Можно сразу видеть отражения этой проблемы к проекту и мотивацию членов команды. Это просто не идет "гладко".

Я надеюсь, что это помогает. Сохраните их зелеными! (unittests, который является),

править: "Нажатие кнопки" Вы обращаетесь к, "одноэтапная сборка". Это означает, что у Вас есть сценарий, который делает Вашу сборку (или муравей или знаток, или безотносительно), и Вы используете тот сценарий, чтобы сделать тесты aswel. Таким образом, когда Ваш автоматизированный buildprocess работает, Вы знаете, что у Вас есть shippable продукт. Вы просто запускаете скрипт и отправляете вывод клиенту. Наш сценарий сборки производит структуру каталогов, которая копируется 1 на 1 в CD, с которым мы поставляем программное обеспечение.

3
ответ дан 5 December 2019 в 05:08
поделиться

На моем текущем концерте мы делаем, по крайней мере, ежедневную сборку нашего Java использование приложения EE CruiseControl, Плющ repo, Ant & ClearCase. Мы - многочисленная команда и способный предоставить команду сборки (3) и серверы сборки.

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

1
ответ дан 5 December 2019 в 05:08
поделиться
Другие вопросы по тегам:

Похожие вопросы: