IBM BluemixDevelop in the cloud at the click of a button!

Da implementação manual para a implementação contínua automatizada de aplicativos remotos do Worklight

Desenvolvimento e implementação contínuos dos aplicativos remotos Worklight com o IBM UrbanCode Deploy

Este artigo mostra como usar o IBM UrbanCode Deploy para definir uma solução de implementação DevOps para artefatos remotos do IBM Worklight. Ao definir uma implementação usando o IBM UrbanCode Deploy com o plug-in do IBM Worklight, as equipes remotas podem responder ao feedback mais rapidamente e ter um processo repetível com risco reduzido.

Joel Cayne, Software Developer, IBM

Photo of Joel CayneJoel é desenvolvedor de software da equipe IBM Rational Mobile Solutions no laboratório da IBM Canadá. Ele já trabalhou em outros produtos IBM, como o IBM Rational Application Developer, e como committer no projeto Eclipse Test and Performance Tools Platform (TPTP). Joel tem mestrado em Ciência da Computação pela Universidade de Nova York.



25/Abr/2014

Introdução

Em resposta à demanda dos clientes pelo acesso a dados a partir de dispositivos móveis, um número cada vez maior de aplicativos agora inclui componentes remotos. A mudança para a mobilidade significa que as equipes de desenvolvimento devem se adaptar às demandas de ciclo de vida específicas do desenvolvimento remoto. As equipes devem liberar frequentemente novas versões de aplicativos remotos em resposta ao feedback de clientes e testadores ou por causa de mudanças no backend (por exemplo, atualizações em um banco de dados ou serviço da web). Para acompanhar a demanda dos usuários, as equipes de desenvolvimento remoto e operações têm que implementar ciclos de desenvolvimento curtos. Essas equipes recorrem às práticas de desenvolvimento contínuo e entrega contínua do DevOps.

Integração contínua é a prática pela qual os desenvolvedores entregam, repetidamente, mudanças em um repositório de código fonte e um sistema de construção integra as mudanças à saída de construção. Usando a saída da construção, a entrega contínua implementa os artefatos nos sistemas de destino. Já que a integração contínua aumenta o número de novas construções disponíveis para teste, a equipe de operações deve atualizar os ambientes de implementação com maior frequência. Para ajudá-la a gerenciar o aumento da demanda de implementações, as equipes de operações adotam princípios de entrega contínua.

A entrega contínua ajuda a fornecer processos de implementação repetíveis para instalar e configurar a nova saída, possivelmente a partir de saídas de construção diferentes, em configurações e sistemas de backend diferentes, como mostra a Figura 1. Adotando a entrega contínua, o código é verificado antes e as mudanças no código podem ser incluídas na construção pelo desenvolvedor original, enquanto as ideias ainda estão frescas na cabeça.

Figura 1. Topologia típica da entrega contínua remota

Na maioria das equipes, a integração contínua para os projetos já está implementada. Agora as equipes estão sendo solicitadas a melhorar o processo de implementação e a interação com o aplicativo por meio de uma interface remota. O® Worklight® Studio fornece aos desenvolvedores um ambiente ideal para criar um frontend remoto para direcionar a vários tipos de dispositivo por meio de aplicativos da web, híbridos, híbridos mistos ou remotos nativos. O® UrbanCode® Deploy permite que as equipes de desenvolvimento realizem a entrega contínua ao implementar artefatos. Com o UrbanCode Deploy, o processo de implementação é automatizado. A equipe usa etapas de processo do tipo arrastar e soltar para criar graficamente sequências de ações (processos) para realizar nos aplicativos e seus componentes. O plug-in do IBM Worklight para IBM UrbanCode Deploy possibilita a implementação em ambientes que englobam o IBM® Worklight® Server.

O processo de desenvolvimento remoto descrito neste artigo ajuda a levar o aplicativo do desenvolvimento e da construção até a implementação no ambiente do IBM Worklight Server para uso em um dispositivo móvel. Estão incluídos neste artigo scripts da amostra para ajudar a realizar a entrega contínua para a plataforma remota.


Visão geral do processo de desenvolvimento remoto

De modo geral, o desenvolvimento móvel tem as seguintes fases, mostradas na Figura 2:

  1. Desenvolver o aplicativo.
  2. Entregar as mudanças para o sistema de gerenciamento de código fonte (SCM).
  3. Desenvolver o aplicativo.
  4. Implementar os artefatos criados pela construção.
  5. Instalar e usar o aplicativo remoto.
Figura 2. Visão geral do processo de entrega contínua remota

Neste artigo, as seguintes ferramentas são usadas para implementar o processo de desenvolvimento remoto:

  • Para desenvolver o aplicativo: IBM Worklight Studio 6.0.0
  • Para entregar as mudanças para o SCM: IBM® Rational Team Concert™ 4.0.3
  • Para desenvolver o aplicativo: Build System Toolkit 4.0.3
  • Para implementar os artefatos: IBM UrbanCode Deploy 6.0.0
  • Para agir como servidor de aplicativos: IBM® WebSphere® Application Server 8.5.5
  • Para agir como servidor enterprise: IBM Worklight Server 6.0.0
  • Para implementar em ambientes do Worklight Server: Plug-in do IBM Worklight 1.0

Observação: É possível usar outras ferramentas para implementar o processo. Por exemplo, é possível usar o IBM® WebSphere® Application Server Liberty Profile em vez do IBM WebSphere Application Server.

Desenvolva e entregue o aplicativo

O processo de desenvolvimento começa quando o desenvolvedor cria ou modifica o aplicativo remoto no IBM Worklight Studio e compartilha o projeto com a equipe no sistema Rational Team Concert SCM.

Desenvolva o aplicativo

O projeto é construído pelo IBM® Rational® Jazz™ Build Engine, um componente do Jazz Build System Toolkit. Em seguida, os artefatos do IBM Worklight criados pela construção são incluídos no CodeStation, um repositório de artefatos que faz parte do IBM UrbanCode Deploy. O CodeStation também rastreia as versões dos artefatos e mantém uma cópia das versões.

Implemente e instale o aplicativo

Os artefatos criados pela construção são implementados no ambiente de destino automaticamente pelo IBM UrbanCode Deploy. No caso de um aplicativo remoto híbrido, os artefatos são implementados no WebSphere Application Server e no IBM Worklight Server. Em seguida, o aplicativo atualizado pode ser instalado a partir do Application Center (um dispositivo do IBM Worklight que funciona como um armazenamento de aplicativos interno) no dispositivo móvel ou simulador/emulador, como mostra a Figura 3.

O processo poderá ser repetido quando o aplicativo for atualizado.

Figura 3. Visão geral do processo de implementação remota

Clique para ver a imagem maior

Figura 3. Visão geral do processo de implementação remota

A Figura 4 mostra as quatro fases do processo de implementação remota. Este artigo demonstra como usar o plug-in do Worklight para realizar a fase de implementação do ciclo de vida.

Figura 4. Detalhamento do processo de desenvolvimento

Clique para ver a imagem maior

Figura 4. Detalhamento do processo de desenvolvimento


Configure o processo de integração e entrega contínuas

Para configurar um aplicativo remoto que adota a entrega contínua DevOps, realize as tarefas a seguir:

  1. Entenda o ambiente de desenvolvimento e os artefatos do IBM Worklight Studio.
  2. Configure o sistema de construção.
  3. Configure o IBM Worklight Server.
  4. Configure a implementação no IBM UrbanCode Deploy para a implementação contínua.
  5. Use o aplicativo remoto.

Com esse conjunto de tarefas, é possível modificar, reconstruir e reimplementar facilmente um aplicativo remoto. Use o processo descrito aqui e os scripts da amostra incluídos neste artigo para customizar o processo para ajustá-lo ao seu cenário.

Entenda o ambiente de desenvolvimento e os artefatos do IBM Worklight Studio

Este cenário explica como desenvolver um aplicativo remoto híbrido. Com a abordagem de aplicativo remoto híbrido, a funcionalidade comum pode estar contida no servidor, para que o aplicativo possa ser escrito uma vez para usar em diversas plataformas nativas.

No IBM Worklight Studio, o aplicativo remoto é criado em um projeto do Worklight, como mostra a Figura 5. Neste exemplo, o projeto é chamado JKEBankMobile (anotação 1), um aplicativo financeiro remoto híbrido.

O projeto inclui as seguintes partes:

  • Dois adaptadores (anotação 2), que definem o acesso aos serviços, como um adaptador para se conectar a entidades beneficentes para fazer doações.
  • Código comum do aplicativo híbrido, como a página de login no banco, que está contida na pasta comum (anotação 3). O código comum do aplicativo é implementado como aplicativo do IBM Worklight (.wlapp) no IBM Worklight Server.
  • Código específico para o sistema operacional. O aplicativo de exemplo JKEMobile inclui o suporte para ambientes Android™ e iOS® (anotação 4).
Figura 5. Layout do projeto do Worklight

Ao construir o projeto do IBM Worklight, alguns dos artefatos a seguir (ou todos eles) são gerados:

  • O arquivo binário nativo instalado no dispositivo móvel. Esse arquivo pode ser transferido por upload para o IBM Worklight Application Center.
  • No caso de um aplicativo híbrido do IBM Worklight, um aplicativo .wlapp, que contém os metadados e recursos do aplicativo, como páginas de JavaScript. O aplicativo híbrido é instalado no IBM Worklight Console.
  • Um arquivo de adaptador com código do lado do servidor — por exemplo, para acessar origens de dados — é transferido por upload para o IBM Worklight Console.
  • Arquivo WAR do projeto do IBMWorklight, que contém informações de configuração específicas para o servidor. Esse aplicativo é instalado no servidor de aplicativos.

Configure o sistema de construção

O sistema de construção manipula a construção dos artefatos do IBM Worklight e outros artefatos relacionados. Nesse processo, uma construção baseada em Apache Ant do Rational Team Concert® é usada para construir os artefatos. O ambiente de construção é configurado com:

  • Um mecanismo de construção para construir os artefatos
  • Um arquivo JAR Ant do IBM Worklight para construir os artefatos do Worklight
  • Um SDK nativo para construir o aplicativo nativo

No Rational Team Concert, é necessário definir os seguintes recursos:

  • Um mecanismo de construção para construir os artefatos. Esse exemplo usa o Jazz Build Engine. O mecanismo de construção é criado para executar o processo na máquina identificada pelo nome do mecanismo (por exemplo default, que está aguardando trabalho na lista de mecanismos da Figura 6).
  • Uma definição de construção para definir propriedades específicas para a máquina de construção em que o Jazz Build Engine executa. Na Figura 6, a definição de construção Android build é usada para construir os artefatos remotos do Android. A máquina de construção requer o arquivo JAR Ant do IBM Worklight que contém as tarefas de construção para construir os artefatos. O arquivo JAR é obtido a partir do IBM Worklight Server.
Figura 6. Configuração de construção do Rational Team Concert

Este artigo inclui scripts de construção da amostra que você pode usar como modelo para configurar o ambiente de construção de aplicativos remotos do IBM Worklight. Também é possível criar seus próprios scripts de construção que constroem os artefatos do IBM Worklight. Para atualizar os scripts de construção da amostra para o seu cenário ou criar seus próprios scripts de construção, use as tarefas de Ant mostradas nas Listagens 1, 2 e 3 para construir artefatos do IBM Worklight. Essas tarefas de Ant, incluídas no arquivo JAR Ant do IBM Worklight, constroem o aplicativo híbrido, o arquivo do adaptador e os artefatos do projeto do Worklight.

Listagem 1. Aplicativos híbridos usando a tarefa de Ant app-builder
<app-builder
        nativeProjectPrefix="Your project name"
        applicationFolder="Path to your source"
        outputFolder="Output location"
        worklightserverhost="Worklight Server host URL"/>
Listagem 2. Arquivos de adaptador que usam o a tarefa de Ant adapter-builder
<adapter-builder
    folder="Path to your source"
    destinationFolder="Output location" />
Listagem 3. Projetos do Worklight que usam a tarefa de Ant war-builder
<war-builder projectfolder="Path to your project"
             destinationfolder="Output location"
             warfile="Output location and file name"
             classesFolder="Compiled classes folder"/>

Em seguida, construa o aplicativo nativo chamando os comandos do SDK nativo. Por exemplo, chame o comando android para aplicativos do Android, e os comandos xcodebuild e xcrun para aplicativos do iOS.

Quando a construção for concluída, será realizada a saída dos artefatos para um local de saída da construção. Por exemplo, ao usar o Rational Team Concert, os artefatos podem ser armazenados no resultado da construção, como mostra a Figura 7. Esses artefatos de construção devem ser incluídos no CodeStation do IBM UrbanCode Deploy para implementação.

Figura 7. Artefatos de construção armazenados em um resultado de construção

Inclua artefatos de construção no CodeStation como versões de componente

Os aplicativos no IBM UrbanCode Deploy podem representar o projeto completo, e um componente pode ser usado para representar um subconjunto (por exemplo, o componente remoto de um aplicativo financeiro geral). Da mesma forma que nos repositórios de código fonte, no IBM UrbanCode Deploy, o CodeStation é usado para gerenciar versões para implementação no nível do componente. Os scripts de construção da amostra incluem dois métodos para incluir artefatos em uma versão de componente no IBM UrbanCode Deploy:

  • Um sistema de arquivos com versão
  • O cliente da linha de comando para incluir artefatos no CodeStation

O sistema de arquivos com versão usa uma estrutura de diretório no sistema de arquivos para manter versões. Nesta abordagem, o diretório raiz do componente contém subdiretórios com os nomes de versão (por exemplo, 1.0.0 e 1.0.1, como mostra a Figura 8). Para criar uma nova versão, inclua um novo diretório para conter o conteúdo de construção mais recente. Dê um nome ao novo diretório usando a versão subsequente (por exemplo, dê ao diretório o nome 1.0.2). A nova versão aparece no CodeStation.

Para copiar arquivos para um sistema de arquivos com versão, use o código Ant mostrado na Listagem 4.

Listagem 4. Código Ant para copiar arquivos para um sistema de arquivos com versão
<copy todir="Versioned file system directory">
    <fileset dir="Output location"/>
</copy>
Figura 8. Amostra de sistema de arquivos com versão em C:\mobile contendo duas versões, 1.0.0 e 1.0.1

Usar o cliente da linha de comando (CLI) para criar versões e fazer upload de arquivos para CodeStation é uma abordagem alternativa. O CodeStation armazena artefatos dentro do IBM UrbanCode Deploy e não requer acesso ao sistema de arquivos para adicionar os artefatos de versão. Use os comandos a seguir:

  1. Crie uma nova versão no CodeStation usando o CLI. Por exemplo:
    udclient -weburl https://localhost:8443 createVersion -component "Mobile" -name 1.0.0
  2. Inclua os artefatos no CodeStation usando o comando de CLI a seguir:
    udclient -weburl https://localhost:8443 addVersionFiles -component "Mobile" -version 1.0.0 -base C:\rootDirectory

Também é possível gravar essas chamadas de CLI no Ant. Por exemplo, para incluir os artefatos, use o seguinte código mostrado na Listagem 5.

Listagem 5. Inclua artefatos
<exec executable="${udclientPath}/udclient"
    failonerror="false"
    resultproperty="artifact-add-result"
    output="${logLocation}">
    <arg line="-weburl urbancode-web-url -username urbancode-username 
-password urbancode-password createVersion -component component-name -name version-name" />
</exec>

Scripts de construção da amostra

Os scripts Ant da amostra que foram incluídos constroem os quatro artefatos do IBM Worklight (binário nativo, aplicativo híbrido, adaptador e projeto do Worklight) com base nas tarefas Ant descritas em Configurando o seu sistema de construção . Estão incluídos scripts para os sistemas operacionais Android e iOS. Para customizar os scripts de construção para o seu ambiente e o seu projeto, consulte os comentários dentro dos scripts de construção para ver as instruções.

São fornecidos os dois scripts a seguir para implementar no UrbanCode Deploy:

build-copy.xml
Usa o sistema de arquivos com versão para criar novas versões de componente.
build-push.xml
Usa o CLI para realizar o push para o CodeStation.

Nos scripts de construção, quando os artefatos do IBM Worklight são compilados, a saída da construção é transferida por upload para o Rational Team Concert e implementada no IBM UrbanCode. Os arquivos de criação de log e de saída do Rational Team Concert estão incluídos para ajudar a depurar e rastrear as construções.

Visão geral dos destinos nos scripts da amostra

Os destinos de Ant dentro dos scripts da amostra fornecem o processo para construir os artefatos do IBM Worklight. Esses scripts podem ser customizados para incluir destinos adicionais, conforme a necessidade, para o seu aplicativo.

  1. A construção começa com o destino all.
    <target name="all" depends="hybrid,androidNative,worklightProject,fileSystemPush" />
  2. O destino hybrid é chamado e constrói o aplicativo híbrido e o adaptador usando as tarefas app-builder e adapter-builder descritas na seção Configurando o seu sistema de construção. O adaptador, o aplicativo híbrido e os arquivos de log são transferidos por upload para os resultados de construção do Rational Team Concert.
  3. O aplicativo nativo é construído com o SDK específico para remotos, usando o destino androidNative para Android no exemplo incluído.
  4. O aplicativo IBM Worklight é construído no destino worklightProject usando a tarefa Ant war-builder.
  5. A saída de construção é incluída como uma nova versão de componente no IBM UrbanCode Deploy, no destino fileSystemPush. A nova versão do componente se baseia na versão do aplicativo.

Configure o IBM Worklight Server

É no ambiente de implementação que o IBM Worklight Server e o software necessário usado no aplicativo remoto (por exemplo, serviços) são instalados. Um ambiente de implementação típico inclui um IBM Worklight Server (com o Application Center instalado), servidor de aplicativos e banco de dados. Observe que o ambiente de implementação pode ter elementos que são remotos. Por exemplo, o IBM Worklight Server pode estar em uma máquina separada do serviço REST usado no aplicativo remoto.

Para cada aplicativo remoto que você constrói, é necessário configurar um console no IBM Worklight Server. O adaptador (que dá acesso a origens de dados como serviços da web) e o aplicativo híbrido (que inclui metadados do aplicativo e recursos da web) podem ser implementados no console.

Para criar o IBM Worklight Console:

  1. Configure o banco de dados do IBM Worklight e o banco de dados de relatórios, manualmente ou usando tarefas Ant.
  2. Implemente o projeto IBM Worklight manualmente ou usando tarefas Ant.

Dica: É possível executar as tarefas Ant de dentro de um processo no IBM UrbanCode Deploy usando o plug-in de Ant em vez de usar a linha de comando.

O script Ant da amostra configure-was-derby.xml fornecido na instalação do IBM Worklight configura um banco de dados Derby e instala o aplicativo no WebSphere Application Server (o script se encontra em Worklight/WorklightServer/configuration-samples). Por exemplo, use as duas etapas a seguir na linha de comandos para configurar o console e realizar a saída para um arquivo de log:

  1. ant –f configure-was-derby.xml –l db.txt databases
  2. ant –f configure-was-derby.xml –l was.txt install

Dica:se você implementar vários aplicativos, crie consoles individuais com suas próprias raízes de contexto e um ID exclusivo. Para fazer isso, atualize as propriedades mostradas na Listagem 6.

Listagem 6. Propriedades a serem atualizadas no destino de instalação do script configure-was-derby.xml
<configureapplicationserver shortcutsDir="${shortcuts.dir}"
                            contextroot="/${worklight.project.context}"
                            id="${worklight.project.context}">

Observação: Talvez seja necessário reiniciar o servidor de aplicativos depois de criar o Application Center e o console.

Configure a implementação no UrbanCode Deploy

Você configurou a construção — isso incluiu os artefatos de construção em uma nova versão de componente no CodeStation. Na Figura 9, é possível ver um exemplo de duas versões de componente no UrbanCode Deploy.

Figura 9. Versões do componente da forma que são vistas no UrbanCode Deploy

A Figura 10 mostra o conteúdo da versão do componente, que é a saída da construção.

Figura 10. Artefatos da versão do componente

Depois de incluir os arquivos em uma versão no IBM UrbanCode Deploy, é necessário definir um processo para implementar os artefatos do IBM Worklight da construção para o IBM Worklight Server.

O IBM UrbanCode Deploy mapeia a implementação do aplicativo no aplicativo, seus componentes, os processos para realizar a ação e o ambiente em que implementação deve ser realizada. A Figura 11 mostra o relacionamento entre o aplicativo, o componente e seus processos.

Figura 11. Aplicativo, componentes e processos

Neste exemplo, o aplicativo JKEMobile, como mostra a Figura 12 com outro aplicativo Application, representa o projeto financeiro geral em desenvolvimento. Os aplicativos contêm componentes, ou seja, as partes que compõem todo o aplicativo financeiro, como banco de dados, web e remoto. Esse método permite que o aplicativo seja dividido em partes consumíveis para que as ações de implementação possam ser realizadas em um nível mais baixo quando novas versões de componente estejam disponíveis.

Figura 12. Lista de aplicativos

O componente JKEMobile – Android, como mostra a Figura 13, define o processo de implementação remota para o aplicativo JKEMobile.

Figura 13. Lista de componentes

Processos são definidos com etapas, os seja, ações a serem realizadas durante a implementação do componente ou aplicativo. Os processos de componente definem o trabalho propriamente dito que deve ser feito usando as etapas em um diagrama de processo. No nível do aplicativo, os processos podem ser usados para instalar os diversos componentes para definir uma implementação geral usando processos de componente. Por exemplo, um processo de aplicativo pode atualizar tabelas em um banco de dados, iniciar um servidor de aplicativos e implementar um aplicativo remoto nativo no Application Center. A Figura 15 mostra um exemplo de processo de componente para implementar aplicativos remotos em cinco etapas.

Em cada passo, é possível customizar as propriedades para que elas correspondam ao ambiente. Por exemplo, as propriedades da etapa Transferir o aplicativo por upload para o Application Center, do plug-in do IBM Worklight, são mostradas na Figura 14 e demonstram como os atributos podem ser customizados. Nesta etapa, é possível fornecer informações específicas para o IBM Worklight Server, como a raiz de contexto e o nome do aplicativo nativo — por exemplo: JKEMobile-debug.apk.

As propriedades nas etapas do processo podem ter valores padrão. Os valores padrão são referências para valores que você normalmente define em outras partes do IBM UrbanCode Deploy, como quando você cria o componente ou ambiente. Por exemplo, na Figura 14, o valor padrão do contexto é ${p:component/applicationCenterContext} — isso significa usar o valor definido para applicationCenterContext no componente.

Observação: É possível inserir um valor diferente para a propriedade.

Figura 14. Propriedades da etapa Transferir o aplicativo por upload para o Application Center

Dica: Em uma implementação de aplicativo remoto, os artefatos que devem ser implementados nos servidores devem ser incluídos em um processo na seguinte ordem:

  1. Implemente ou atualize o projeto do IBM Worklight.
  2. Implemente o adaptador no IBM Worklight Console.
  3. Implemente o aplicativo híbrido no IBM Worklight Console. (Pode ser implementado em paralelo com o adaptador.)
  4. Implemente o aplicativo nativo no Application Center.

A Figura 15 usa as etapas fornecidas no plug-in do IBM Worklight, além dos plug-ins do servidor de aplicativos (por exemplo, o plug-in do WebSphere Application Server), para implementar artefatos de aplicativo remoto no IBM Worklight Server. Estas são as ações realizadas no processo de componente:

  1. A etapa Fazer o download dos artefatos recupera os artefatos de versão do componente do UrbanCode Deploy para a máquina do agente, para usar com as etapas de processo restantes.
  2. O arquivo da web do projeto do IBM Worklight é atualizado no servidor de aplicativos usando a etapa Instale ou atualize o aplicativo do plug-in do WebSphere. Esta etapa possibilita a atualização de quaisquer definições de configuração.
  3. Duas etapas são executadas em paralelo a partir do plug-in do IBM Worklight: Implemente o adaptador no Worklight Server e implemente o aplicativo híbrido no IBM Worklight Server. Os artefatos transferidos por upload por essas etapas fornecem os recursos do lado do servidor para o aplicativo remoto.
  4. Depois de concluir as duas etapas com sucesso, o aplicativo nativo é transferido por upload para o Application Center usando a etapa Transferir o aplicativo por upload para o Application Center, do plug-in do IBM Worklight.
Figura 15. Processo do componente de amostra para implementar os artefatos do IBM Worklight

Quando a implementação é concluída com sucesso, é possível instalar em um dispositivo a partir do Application Center para verificação. É possível construir e reimplementar no IBM Worklight Server quaisquer atualizações posteriores do aplicativo remoto usando o mesmo processo de implementação.

Dica: Um ambiente define os recursos usados para a implementação. É onde o processo deve ser executado. No IBM UrbanCode Deploy, é possível definir vários ambientes de implementação, como desenvolvimento (Dev) e garantia de qualidade (QA), como mostra a Figura 16, em que o mesmo processo pode ser customizado para implementar em diversas configurações.

Figura 16. Lista de ambientes

Depois que você executa o processo de implementação, os artefatos ficam disponíveis no Application Center, como mostra a Figura 17. No exemplo, o mesmo aplicativo remoto é implementado, mas é direcionado a ambientes de dispositivo nativo diferentes (iOS e Android).

Figura 17. Aplicativos de amostra no Application Center

Clique para ver a imagem maior

Figura 17. Aplicativos de amostra no Application Center

A Figura 18 mostra um IBM Worklight Console com o aplicativo híbrido JKEMobile instalado e os dois adaptadores do aplicativo: JKEAdapter e JKELegacyAdapter.

Figura 18. Adaptadores do Worklight de amostra e aplicativo do Worklight em um console

Clique para ver a imagem maior

Figura 18. Adaptadores do Worklight de amostra e aplicativo do Worklight em um console


Expanda a amostra

É possível expandir os scripts de construção de amostra fornecidos com este artigo para implementar em diversos ambientes. Por exemplo, se o projeto do IBM Worklight é direcionado para Android e iOS, é possível:

  1. Combinar os destinos do script de construção para integrar os aplicativos nativos em um arquivo de construção.
  2. Inclua uma etapa adicional no processo de componente, como mostra a Figura 15, para fazer upload dos dois aplicativos nativos para o Application Center.

As etapas fornecidas pelo plug-in do IBM Worklight fornecem a flexibilidade para criar um processo que se ajusta ao seu aplicativo remoto. Por exemplo, se o seu aplicativo inclui diversos adaptadores, é possível incluir diversas etapas de implementação de adaptadores no processo. Como mostra a Figura 15, as etapas fornecidas pelo plug-in do IBM Worklight fornecem flexibilidade para customizar processos a fim de implementar diversos aplicativos remotos no mesmo IBM Worklight Server ou em outro. A implementação no mesmo servidor tem o auxílio dos valores padrão que podem ser configurados no nível do componente. Por exemplo, na Figura 14, a propriedade File pode usar a propriedade application configurada no nível do componente. No componente de Android, a propriedade de componente application pode apontar para JKEMobile-debug.apk e, em um componente de iOS, a propriedade de componente application pode ser configurada para o artefato do arquivo do aplicativo de iOS (.ipa).

Além do processo para implementar artefatos remotos, os processos de implementação podem ser incluídos em outros processos de negócios na empresa, como web, banco de dados, etc.


Resumo

As equipes de desenvolvimento estão procurando formas de responder ao feedback mais rapidamente. A integração contínua ajuda a reduzir o tempo necessário para construir artefatos de aplicativo. Combinado com a implementação contínua por meio do DevOps usando o IBM UrbanCode Deploy, o tempo de implementação pode ser reduzido fornecendo processos repetíveis para implementar os artefatos de construção. Já que as equipes de desenvolvimento remoto geralmente têm ciclos de desenvolvimento curtos, o plug-in do IBM Worklight pode ajudar a criar um processo repetível para implementar artefatos de aplicativos remotos no IBM Worklight Server. O plug-in permite que as equipes de DevOps respondam ao feedback mais rapidamente e atualizem os processos de atualização da implementação com facilidade. As informações fornecidas neste artigo explicam as etapas que podem ser aplicadas para usar o IBM UrbanCode Deploy com o plug-in do IBM Worklight para implementar no IBM Worklight Server.

Agradecimentos

Gostaria de agradecer a Derek Baron, Jinzi Huang, Mike Melick, Chris Jeffs e todos os demais que ajudaram, contribuindo com opiniões, revisões e tempo investido na redação deste artigo.


Download

DescriçãoNomeTamanho
Sample build scripts for this articleSampleBuildScripts.zip16KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational, Desenvolvimento móvel
ArticleID=969704
ArticleTitle=Da implementação manual para a implementação contínua automatizada de aplicativos remotos do Worklight
publish-date=04252014