Обновление приложения Grails с версии 1.3.7 до версии 2.4.4

Итак, вы хотите обновить свое приложение до Grails 2.4.4  с этой устаревшей версии 1.3.7  сегодня!

Но ждать! В этом процессе вас ждет мало испытаний.

1. Старт

Подумайте: с чего начать обновление? Это довольно сложная задача для корпоративного приложения, на котором может работать весь ваш бизнес. Любая ошибка вводится в процессе, и вы тост ! Но вот идут испытания,  чтобы спасти нас ! Вы можете спросить: «Какие тесты ?» Я объясню их, я обещаю.

Давайте начнем с некоторой теории и предстоящих проблем!

• Обновление приложения — это не просто изменение номера версии в  файле application.properties . Это больше, чем это! У вас есть «x» количество плагинов, некоторые из которых вы сделали своими силами, которые обслуживаются из вашего хранилища и размещаются в централизованно работающем  экземпляре Artificatory ! И, конечно же, плагины от Maven  имеют свою собственную историю. Есть еще плагины; помните плагины на месте? Вы должны обновить их также.

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

• У вас есть различные параметры среды и свойства конфигурации в файлах BuildConfig.groovy  и Config.groovy  . Теперь им потребуется ваше особое внимание, то есть проверка их совместимости.

• Ваше приложение использует систему Grails i18n  , а управление пользователями осуществляется в соответствии с их языковым стандартом. Вы знаете, что здесь много работы, но будьте уверены, поскольку Grails  и  класс java.util.Locale окажут вам поддержку.

• У вас есть очень большой  файл UrlMappings.groovy, который содержит огромные записи URL-адресов, и если этого недостаточно, вы получаете их в разных локализованных версиях!

Это были некоторые из проблем, которые я только что упомянул.

2. Подготовка и процесс мышления

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

Между версиями Grails 1.3.7  и 2.4.4 произошли довольно серьезные изменения,  например ApplicationHolder , ConfigurationHolder  устарели в 2.2.4, но были удалены в 2.4.4 и т. Д. Поэтому вместо прямого перехода к самой последней версии в то время ( 2.4.4 ), мы начали серию обновлений с 1.3.7  до 2.2.4  и затем до 2.4.4 . Таким образом, мы застраховали, что наше приложение не сломалось, и таким образом спасли нас от бедствий

Приложение, которое мы только что обновили, имело почти 100% тестовое покрытие, которое включало модульные , интеграционные  и функциональные  тесты. Вот несколько вещей, которые следует учитывать при работе с предыдущими письменными тестами:

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

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

• Я слышал, что у нас  также есть функциональные тесты! «Кто они такие?» Вы можете спросить. Это  тесты Selenium, работающие под прикрытием Geb , для автоматизации браузера, так что вам не нужно каждый раз проверять его вручную, например, Работает ли вход в систему по-прежнему? Просто выполните тест Geb, и он проверит вас. Еще одно замечание: эти тесты работают только с конкретными версиями браузеров. В нашем случае нам пришлось использовать Firefox 32.0.1 (вы также можете использовать Chrome). Конечно, это полностью зависит от версии библиотеки Selenium и драйвера .

3. Обновление

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

1. Первая вещь первая

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

• Возможно, вы захотите начать с настройки значений в файлах Config.groovy  и DataSource.groovy  . Ну, вместо того , чтобы модифицировать эти файлы , вам предлагается указать свой собственный внешний конфигурационный файл , как мой-Config.groovy  и добавить его в grails.config.locations  собственности в Config.groovy. Конфигурация в этом внешнем файле переопределит вашу конфигурацию в файлах Config.groovy и DataSource.groovy. Я рекомендую внешний конфигурационный файл, потому что каждый может иметь свои собственные настройки в одном файле. Конечно, этот файл не должен быть зафиксирован в хранилище и должен быть в списке игнорирования VCS . Это хорошая идея. Это не?

• Одна наиболее заметная конфигурация, которую я нашел полезной, состояла в том, чтобы включить перезагрузку изменений GSP. Grails обычно выполняет свои функции автоматически, но в моем случае это сломалось. Если это также относится и к вам, попробуйте добавить эти свойства во внешний файл конфигурации:

  grails.gsp.enable.reload = true
  grails.reload.enabled = true

• Затем мы должны начать обновление зависимостей в нашем  файле BuildConfig.groovy . Найдите зависимости от репозитория Maven, которые совместимы с текущим  выпуском Grails , каталог плагинов Grails  поможет в этом. По сути, здесь мы пытаемся добиться того, чтобы при обновлении приложения были разрешены все наши зависимости и плагины, чтобы любой код, использующий их, не сломался / не умер во время компиляции.

// Class under test
class MyService {
def someMethod() { return "returning a string." }
}

// Test written with version 1.3.7
import grails.plugin.spock.Unitspec

class MyServiceUnitSpec extends UnitSpec {
    def myService

    def "testing someMethod"() {
        when:
        def result = myService.someMethod()
      then:
      "returning a string." == result
}
}

// Now same test written with version 2.4.4
import spock.lang.Specification

@TestFor(MyService)
class MyServiceUnitSpec extends Specification {
def "testing someMethod"() {
when:
def result = service.someMethod() // Notice the service object!
then:
         "returning a string." == result
    }
}

// Prints every route and associated data
class AppDebugFilters {
    def filters = {
        all (controller: '*', action: '*') {
            before = {
                log.debug "..........AppInfoFilters Start........"
                log.debug "$controllerName/$actionName : $params"
            }
            after = { Map model ->
              log.debug "$model"
            log.debug "..........AppInfoFilters End.........."
            }
            afterView = { Exception e ->
            // Don't need it
            }
        }
    }
}

// BabyController.groovy
class BabyController {
def babbies() {
def baby = new Baby()
      [newBornBaby: baby] // There could be other parameters also e.g., all the babbies in system currently.
    }
}

// babbies.gsp
<g:render template="list" model="[baby:newBornBaby]" />

// _list.gsp
<g:render template="baby" />

// _baby.gsp
<g:set var="clazz" value="${baby ? 'cute' : 'very cute'}" />

// _list.gsp
<g:render template="baby" model="[baby: false]" />

FirefoxDriver driver

def setupSpec() {
driver = new FirefoxDriver(new FirefoxProfile())
}

def cleanupSpec() {
driver.quit() // Never do this!
}