Release Management 2013 (post 3)

Configuração da aplicação (Configure Apps)

Configurar um novo componente, o mesmo será utilizado na configuração de um template de release (próximo passo):Capturar.PNG

Na aba [Source], selecionar a opção [Builds with application]:
Capturar.PNG

Na aba [Deployment], selecionar a opção [XCopy Deployer] no campo [Tool]:
Capturar.PNG

Adicionar variáveis de configuração ao componente:
Capturar.PNG

Configurar um novo template de release:Capturar.PNG

Ao clicar em [New] aparecerá a janela abaixo:

O seguintes campos deverão ser preenchidos:

  • Name;
  • Release Path;
  • Build Definition (Esta nas definições de build do TFS)

Capturar.PNG

Após isso aparecerá uma tela para configurar o workflow de cada processo de deploy, mesma sequencia da configuração do [Release Path]
Capturar.PNG

…estamos quase no final, semana que vem tem mais

Release Management 2013 (post 2)

Definição de Build

No Visual Studio, em [Team Explorer], [Builds], clique em [New Build Definition]
Capturar.PNG

Criar ou Editar uma definição de build:
Capturar.PNG

Existem cinco configurações que deverão ser feitas na definição de build, segue:

  • General;
  • Trigger;
  • Source settings;
  • Build Defults;
  • Process (mais atenção para este item);

General:
Capturar.PNG

Trigger:
Capturar.PNG

Source settings:
Capturar.PNG

Build Defaults:
capturar1.png

Process:
Capturar.PNG

Para o processo de Build é necessário utilizar o arquivo [ReleaseTfvcTemplate.12.xaml] que esta na pasta  [C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin]. Dentro desta opasta estão armazenados vários arquivos com configurações distintas, sendo eles:

• ReleaseDefaultTemplate.11.1.xaml;
• ReleaseDefaultTemplate.xaml;
• ReleaseGitTemplate.12.xaml;
• ReleaseTfvcTemplate.12.xaml;
• ReleaseUpgradeTemplate.xaml;

O arquivo escolhido deve ser incluído dentro de um projeto da solução em questão:Capturar.PNG

Depois de adicionado será necessário vincular ao processo de Build, clique em [New]
Capturar.PNG

Selecione o projeto e o controle de versão:
Capturar.PNG

Para iniciar uma Build clique em [Queue New Build]:Capturar.PNG

Para que a Build funcione corretamente deverá ser configurado o [Controller] e o [Agent] no servidor onde esta instalado o TFS, utilize o [Team Fundation Server Administration Console] opção [Build Configuration] para fazer esta configuração. Observe a imagem abaixo:
Capturar.PNG

…continuação em breve

Release Management 2013 (post 1)

O objetivo deste post e demonstrar como é feita a configuração do software [Release Management 2013 Update 4].

Os passos apresentados a seguir devem ser efetuados na ordem descrita, pois uma configuração especifica pode depender da anterior, como é demonstrado na figura abaixo:

Configuração inicial (Administração)

Verificar o servidor do Release Management Server URL
capturar1.png

Adicionar os servidores de TFS que servirão as demais configurações:
Capturar.PNG

Adicionar os estágios pelo qual o pacote de deploy irá trafegar:Capturar.PNG

Gerenciar os usuários que serão utilizados para as permissões necessários para a transição das builds entre os ambientes:Capturar.PNG

Gerenciar os grupos de usuários que poderão ser utilizados na administração das Builds.Capturar.PNG

Configuração dos caminhos (Configure Paths)

Adicionar servidores para o deploy:
Capturar.PNG

Adicionar os ambientes:
Capturar.PNG

Adicionar os caminhos dos releases (Release path):Capturar.PNG

Ao criar um novo [Path] será necessário configurar as etapas por onde o pacote de deploy ira trafegar:Capturar.PNG

 

Segue alguns links que poderão ajudar:

Revisão de arquitetura

Para fazer revisões de arquitetura devemos considerar alguns pontos importantes.

As soluções/projetos devem estar adequadas ao um padrão especifico, para isso deve-se validar periodicamente a estrutura das mesmos para que sua evolução seja o mantida dentro do padrão, reduzindo o impacto com relação a manutenção/sustentação.

Caracteristicas implícitas

As implementações devem ser analisadas levando em consideração os seguintes aspectos:

  • O que esta sendo feito:
    • Satisfaz os casos de uso/requisitos do sistema;
    • Resiste a mudanças efetuadas no ambiente de implementação;
    • É de fácil manutenção e entendimento;
  • O procedimento de implementação é claro;
  • Tem fácil adaptação a possíveis mudanças validas efetuadas nos requisitos (Nível de dimensionamento mais complexo).

Objetivos diretos

Observar com precisão os seguintes pontos:

  • Dimensionar falhas no disign da solução;
  • Manter a consistência e integridade na arquitetura das aplicações;
  • Identificar oportunidade de:
    • Refactory;
    • Reutilização de código;
    • Criação de componentes;
  • Observar se as fronteiras das camadas são respeitadas no design da aplicação;
  • As camadas estão sendo utilizadas para encapsular as fronteiras conceituais entre os tipos de serviço, Ex:
    • Negocio: domínio da solução;
    • Facade: aplicação, distribuição de fluxos entre web e negocio e demais camadas;
    • Web: interface com o usuário;
    • Infra: cross-cutting, camada transversal que serve as demais;
    • Repositorio: persistência dos dados;
  • A abstração das camadas  facilita a compreensão do design;
  • Detectar incopatibilidade entre os casos de uso:
    • Design execessivo;
    • Requisitos não realistas/ausentes;
  • Analisar aspectos não-funcionais:
    • Desempenho;
    • Confiabilidade;
    • Segurança;

Sugestão de verificação

São necessárias algumas verificações para garantir a qualidade dos fontes em e da estrutura da aplicação, são eles:

  • Mecanismos de Arquitetura/Design
    • Furo de camadas;
    • Documentos/arquivos dispersos;
    • Recuperação ou tratamento de erros;
    • Exibição e interfaces comuns (exibição em janelas, captura de dados, condicionamento de sinais etc.);
    • Para componentes TCE, esta utilizando os pacotes nuGet;
    • Assembly information;
    • Nomenclaturas
      • Pastas;
      • Projetos;
      • Classes;
      • Interfaces;
      • Arquivos;
      • Mensagens;
    • Nível de abstração de componentes;
  • Qualidade:
    • Cobertura de código com relação aos testes unitários;
    • Testes de carga;
    • Testes de regressão;
    • Testes de de interface (Automatizados);
    • (…)
  • Código fonte:
    • Nomespaces;
    • Duplicação de código;
    • “Using” desnecessário;
    • Nomes de variáveis;
    • Heranças;
    • Visibilidade de métodos;
    • Classes por arquivo (Deve ser somente uma classe);
    • Poluição do código:
      • Comentários desnecessários;
      • Metodos sem nenhuma referência;
      • Métodos com escopos vazios;
      • Mensagens/strings fora do resource;
    • Padrões SOLID;
      • Reponsabilidade única;
        • Linhas de código por método;
      • Fechado para alteração, aberto para extenção;
        • Complexidade do método;
      • Deve ser possível substituir uma classe base por suas classes derivadas em quanquer ponto do código.
        • Uso da classe base e herança da forma correta;
      • Classes dependem somente de interfaces e não de classes concretas;
        • Uso do NEW dentro das classes;
      • Injeção de dependência / Inversão de controle;
        • Construtor com as interfaces necessárias;

 

Verificação adicional

A verificação adicional é para garantir a evolução adequada das estruturas paralelas relacionas ao projeto como documentação, banco de dados e versionador de código;

  • Repositorio (Team Explorer)
    • Nomenclatura
      • Pastas;
      • Branches;
    • Banco de dados
      • Nomenclatura
        • Tabelas;
        • Views;
        • StoredProcedures;
        • Funções;
        • Colunas;
        • FK, PK, UK;
      • Normalização adequada;
    • Documentação
      • Técnica (DA – Documento de arquitetura)
        • Visão logica (diagrama de sequência);
        • Visão dos dados (DER);
      • Negocio (UC – Casos de uso);

Padrões

SOLID

Class Design
SRP (Single Responsability Principle / Responsabilidade única): Uma classe ou método deve ter uma única responsabilidade. Deve ter apenas uma razão para mudar.

OCP (Open Closed Principle / Aberto fechado): Uma classe deve sempre estar aberta para EXTENÇÃO e fechada para MODIFICAÇÃO.

LSP (Liskov Substitution Principle / Substituição Liskov): Deve ser possível substituir uma classe base por suas classes derivadas em quanquer ponto do código.

ISP (Interface Segregation Principle / Segregação de interface): Clientes não devem ser obrigados a depender de interfaces que eles não utilizam. Muitas interfaces de um cliente especifico é melhor do que uma interface de uso geral.

DIP (Dependecy Inversion Principle / Inversão dependência): Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações. Abstrações não devem depender de detalhes, detalhes devem depender de abstrações, por exemplo, uma classe deve depender de uma interface ou classe abstrata e não de uma classe concreta.

Package Cohesion

REP (The Reuse Release Equivalency Principle)
CCP (The Common Closure Principle Principle)
CRP (The Common Reuse Principle)

Package Coubling
ADP (The Acyclic Dependencies Principle)
SDP (The Stable Dependencies Principle)
SAP (The Stable Abstractions Principle)

GRASP

Padrões básicos

Information Expert (Especialista de informação): Atribuir uma responsabilidade ao especialista da informação. Classe que possui a informação necessária para cumpri-la.

Creator (Criador): Um objeto deve ser criado por outro que o possua como parte (agregação) ou esteja fortemente associado a ele
High coesion (Alta coesão): Atribuir uma responsabilidade para que a coesão se mantenha alta

Low coupling (Baixo acoplamento): ­ Atribuir uma responsabilidade para que o acoplamento mantenha-se fraco

Controller (Controlador): Atribuir responsabilidades para receber ou lidar com um evento do sistema.
• uma classe que representa todo o sistema ou subsistema (façade controller)
• uma classe que representa cenário de caso de uso (controlador de caso de uso ou de sessão)

Padrões avançados

Polymorphism (Polimorfismo): Não use lógica condicional para realizar alternativas diferentes baseadas em tipo. Atribua responsabilidades ao comportamento usando operações polimórficas.

Pure Fabrication (Invenção pura): Atribuir um conjunto altamente coesivo de responsabilidades a uma classe artificial que não representa um conceito do domínio do problema.

Indirection (Indireção): Atribua a responsabilidade a um objeto intermediário para mediar as mensagens entre outros componentes ou serviços para que não sejam diretamente acoplados.

Protected Variations (Variação protegida): Identificar pontos de variação ou instabilidade potenciais e atribuir responsabilidades para criar uma interface estável em volta desses pontos.

GoF

Creational Patterns
Abstract Factory: Creates an instance of several families of classes
Builder: Separates object construction from its representation
Factory Method: Creates an instance of several derived classes
Prototype: A fully initialized instance to be copied or cloned
Singleton: A class of which only a single instance can exist

Structural Patterns
Adapter: Match interfaces of different classes
Bridge: Separates an object’s interface from its implementation
Composite: A tree structure of simple and composite objects
Decorator: Add responsibilities to objects dynamically
Facade: A single class that represents an entire subsystem
Flyweight: A fine-grained instance used for efficient sharing
Proxy: An object representing another object

Behavioral Patterns
Chain of Resp.: A way of passing a request between a chain of objects
Command: Encapsulate a command request as an object
Interpreter: A way to include language elements in a program
Iterator: Sequentially access the elements of a collection
Mediator: Defines simplified communication between classes
Memento: Capture and restore an object’s internal state
Observer: A way of notifying change to a number of classes
State: Alter an object’s behavior when its state changes
Strategy: Encapsulates an algorithm inside a class
Template: Method Defer the exact steps of an algorithm to a subclass
Visitor: Defines a new operation to a class without change

 

Referência:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

 

Microservices

APLICAÇÕES MONOLÍTICAS

Captura2r

  • Fornece Macro-funcionalidades;
  • Toda a capacidade do negocio/domínio esta em uma mesma funcionalidade ou serviço;
  • Aplicação dividida em camadas;
  • Arquitetura dependente;
  • Deploy simples;
  • Hospedado em um servidor especifico;
  • Desenvolvimento altamente dependente da plataforma;
  • Escalabilidade vertical;
  • Evolução comprometida;
  • Banco de dados integrado:
  • Deploy centralizado:

Capturar1

APLICAÇÕES EM MICRO-SERVIÇOS

Capturar

  • Fornece Micro-funcionalidade;
  • Isola responsabilidades;
  • Solução granular;
  • Divisão de responsabilidades entre projetos/serviços;
  • Alta disponibilidade e escalabilidade;
  • Escalabilidade na capacidade de negocio;
  • Altamente desacoplada;
  • Solução segmentada e distribuída;
  • A aplicação não é desenvolvida em termos de projetos e sim em serviços/produtos;
  • Monitoramento especifico por serviço;
  • Pode ser desenvolvimento em varias plataformas ao mesmo tempo;
  • Dados decentralizados;
  • Banco de dados segmentados;
  • Serviços específicos podem compartilhar bancos de dados distintos;
  • A integração entre serviços pode ser feita através de messageria (RabbitMQ);
  • Deploy descentralizado:

Captura2r

  • Componentização via serviços;

Capturar

 

Referência:
http://martinfowler.com/articles/microservices.html
http://martinfowler.com/microservices
http://microservices.io/

Testes unitários

Segue abaixo alguns conceitos que podem ser aplicados na construção de testes unitários:

  1. Único conceito por teste, ou seja, cada método deve ter uma afirmação;
  2. Não escreva testes grandes demais, quando ficar muito grande deixe-o e escreva testes menores que representem parte dele. Cada teste deve ser o mais simples possível.
  3. Todo método de teste deve ter pelo menos uma assertiva (Assert);
  4. Não faça check-in de testes quebrados;
  5. Isole as dependências de objetos dentro de MOQs ou Fakes (Objetos simulados ou falsos);
  6. Cada classe de teste deve corresponder a uma classe de negócio;
  7. Se necessário, separe os códigos de “Arrange” em uma classe [Partial], assim a classe de teste principal terá somente os métodos de teste;
  8. Nos testes evite:
    1. Conversar com o bando de dados;
    2. Comunicar com a rede;
    3. Ler arquivos externos;
    4. Concorrer com outros métodos de teste;
    5. Configurar ou preparar o ambiente (Externo) para executa-los;
  9. Estruture o seu método de teste em três partes:
    1. Arrange (Preparar os dados para fazer o teste);
    2. Action (Chamar do método a ser testado);
    3. Assert (Testar o resultado obtido);
  10. Dados com significado evidente:
    1. O teste é escrito para alguém ler, serve como documentação do software
    2. Escreva assertivas que representem o objetivo do teste;
  11. Aplique o modelo F.I.R.S.T.
    1. Fast – Rápidos: devem ser rápidos, pois testam apenas uma unidade;
    2. Isolated – Testes unitários são isolados, testando individualmente as unidades e não sua integração;
    3. Repeateble – Repetição nos testes, com resultados de comportamento constante;
    4. Self-verifying – A auto verificação deve verificar se passou ou se deu como falha o teste. Ainda que o objetivo seja o teste de uma falha, o resultado deve ser positivo;
    5. Timely – O teste deve ser oportuno, sendo um teste por unidade.
  12. Aplique os princípios básicos do TDD
    1. Não escreva nenhum código de produção até que tenha escrito antes um teste de unidade que detecte uma falha;
    2. Não escreva mais que um teste de unidade do que o suficiente para a falhar;
    3. Você não pode escrever mais código de produção que sejam suficientes para passar pelo atual teste de unidade;