Mudar para a ramificação 'master' (o branch receptor actual)

$git checkout master
Swtiched to branch 'master'

Listar as linhas de desenvolvimento integradas na master

$git branch --merged
Lista das ramificações mescladas na ramificação principal mestre

Apagar a ramificação local

$git branch -d <nome do branch>
Delete branch <nome do branch> (was a244f48ce)

Exportar a eliminação da ramificação para o repositório central

$git push --delete origin <nome do branch>
To [url repositório git]
-[deleted] <nome do branch>

Remover os objectos git inacessiveis, ou seja, com refs antigas. --dry-run indica o que está marcado para ser removido, mas sem o remover

$git remote prune origin --dry-run
Prunning origin
URL: <url repositório git>
*[would prune] <nome do branch>

Apagar efectivamente as referências para ramificações que não existem no repo remoto

$git remote prune origin
Prunning origin
URL: <url repositório git>
*[prune] <nome do branch>

O comando Prune é considerado um comando de recolha de lixo (garbage collection) e é um comando filho do comando git GC.

O SQLCMD é uma ferramenta de linha de comando que serve para executar comandos e scripts Transact-SQL em instâncias do SQL Server 2008 ou mais recente, podendo utilizar variáveis de ambiente e exportar os resultados para ficheiro. O SSMS também tem um modo SQLCMD que simula a capacidade do SQLCMD e aceita comandos que não fazem parte do T-SQL.

Ferramenta SQLCMD

Modo SQLCMD em SSMS

Exemplo de SQLCMD

:setvar DataDB Kairos
:setvar routineName spChronos
:setvar baseSchema dbo

USE $(DataDB);
GO

IF ('$(dbName)' NOT LIKE DB_NAME())
BEGIN
SET @sql = N'$(dbName) is not a valid database! Aborting definition of ' + QUOTENAME('$(procName)');
RAISERROR(@sql, 16, 127);
END

PRINT 'Creating the ' + QUOTENAME('$(routineName)') + ' Stored Procedure'

IF EXISTS(SELECT 1 FROM [INFORMATION_SCHEMA].[ROUTINES] WHERE [ROUTINE_SCHEMA] = '$(baseSchema)' AND [ROUTINE_NAME] = '$(routineName)' AND [ROUTINE_TYPE] = 'PROCEDURE')
BEGIN

-- Remove the old procedure so we can replace it
DROP PROCEDURE $(baseSchema).$(routineName);

END
GO

CREATE PROCEDURE $(baseSchema).$(routineName)
AS
DECLARE @GO BIT

SET @GO = 1

GO

PRINT '$(routineName) Stored Procedure created'
GO

Referência: Overview of the SQLCMD utility in SQL Server, Working with the SQL Server command line (sqlcmd)

Comandos Git básicos

Preparação

Transferir daqui programa de instalação
Actualização do Git instalado

git clone https://github.com/git/git

Clientes GUI de Git para Windows aqui

Git Extensions

Nutshell

Documento
How to get started with GIT and work with GIT Remote Repo

Vídeo

Get Going (Git-SCM) • Git Basics #3 por GitHub como visto no Vimeo.

fonte: Gartner

Video YouTube, JIRA vs TFS - a side-by-side comparison, 2016




Caso prático de gestão de projecto Agile com VSTS aqui.

Relacionado
Metodologias da Gestão de Projecto

Sistemas Monolíticos

fonte: MongoDB

Um dos principais pontos fracos dos sistemas monolíticos é a existência de um grande ponto único de falha. Isto significa que a ocorrência de um erro pode comprometer todo o sistema, mesmo as funcionalidades que não têm nenhuma relação com esse incidente. Por exemplo, uma falha no registo de funcionários de um ERP que deixe o sistema fora do ar pode limitar a geração de contratos para clientes. Outro ponto fraco é a base de código, que se torna muito extensa, podendo deixar novos membros do projecto menos produtivos durante algum tempo, já que a complexidade do código é muito maior.

Por outro lado, temos um sistema cujo DEPLOY é fácil, já que a base de dados facilmente evoluirá com as outras componentes para todas as funcionalidades e há apenas um ponto onde o DEPLOY tem de ser executado. Além disso, não há duplicação de código e de classes entre os vários módulos, já que todas elas fazem parte da mesma unidade.

Micro Serviço

Um micro serviço é uma componente de alta coesão, baixo acoplamento, autónoma e independente, que representa um contexto de negócio de uma aplicação.

Arquitectura de Micro Serviços

fonte: MongoDB

Particionar uma aplicação em unidades independentes, autónomas, de alta coesão e baixo acoplamento. Uma das grandes vantagens é que os micro serviços devem ser criados, mantidos, executados e distribuídos de forma totalmente independente.

Trata-se de uma arquitectura que permite que pequenos serviços de aplicação coexistam e comuniquem entre si, de modo seguro, escalável e permitindo que os novos serviços possam ser incluídos na plataforma a qualquer momento, complementando as funcionalidades já existentes. De salientar que não se trata de um único produto composto por múltiplos serviços relacionados entre si, mas sim de uma plataforma de agregação de serviços. É possível haver uma instância da plataforma que agregue serviços de CRM, outra que agregue serviços de ERP e outra para serviços de POS, cada uma delas constituindo um sistema distinto. Ainda assim, para cada uma destas plataformas, existe a possibilidade de agregar novos serviços, incluindo alguns que sejam responsáveis exclusivamente pela interacção entre os diferentes sistemas.

Como Distribuir Micro Serviços

fonte:MongoDB

Duas características importantes dos micro serviços são: Autonomia e Independência, o que significa que se pode fazer deploy de um micro serviço, sem ter que recompilar os outros ou os seus "clientes".
Para evitar esse acoplamento, cada micro serviço é instalado num host diferente. Host diferente não implica máquina física distinta, pode ser uma arquitectura de VMs (Azure), de Light Containers LXC (Docker - poderiamos distribuir os micro serviços como aplicações Docker) ou frameworks de orquestração (Kubernetes, Mesos).

Os micro serviços comunicam entre si e com os clientes usando mecanismos standard e agnósticos de tecnologia, como HTTP e REST. Os micro serviços são componentes autónomas e de baixo acoplamento, portanto, não têm de ser construídos com a mesma linguagem nem processados na mesma plataforma.

Como Ficam as Aplicações?

Com micro serviços podemos criar novas aplicações por composição, agregando os micro serviços que julgarmos necessários, sem camada de persistência, pois os dados são tratados apenas por cada micro serviço específico.

Aqui o padrão Backends for Frontends consiste em criar módulos agregadores, para cada página, que consomem os micro serviços e montam as áreas de conteúdo para a página.



(editado)

vide Microservices, a definition of this new architectural term







fonte: Micro serviços: O que são e para que servem?, Arquitetura de microserviços ou monolítica?

Video YouTube, Putting Quality First through Continuous Testing | Adam Auerbach | StickyMinds






fonte: Putting Quality First through Continuous Testing: STARWEST 2015 Interview with Adam Auerbach

O que é

Em síntese, DevOps development and operations é uma abordagem baseada nos princípios Agile que permite aos donos do negócio e ao desenvolvimento, operações e QA quality assurance colaborarem de maneira a entregar software de forma contínua, a agarrar mais rapidamente as oportunidades de negócio e a reduzir o tempo para obter feedback. De facto, as aplicações empresariais são tão distintas e compostas de tantas tecnologias, bases de dados e dispositivos terminais que apenas uma aborgadem DevOps development and operations pode ser bem sucedida ao lidar com este tipo de complexidade.

Quando e como é usado

Uma abordagem DevOps development and operations inclui as linhas de negócio, as TI Tecnologias de Informação, os executivos, os parceiros, os fornecedores e outras partes interessadas.

Usar uma abordagem DevOps é benéfico sempre que:

• estão em desenvolvimento aplicações complexas que requerem processos de instalação complexos
• é necessário dar suporte e garantir o trabalho de muitos computadores
• são necessárias releases frequentes
• é importante monitorizar a aplicação em produção e resolver os bugs rapidamente

Nestas circunstâncias o mais importante é o tempo: é importante reduzir o tempo despendido na instalação e é importante acelerar o feedback para a equipa de desenvolvimento.

Processos da ALM

A ALM Application Lifecycle Management é o conjunto de processos aplicados na gestão de uma aplicação desde a ideia (necessidade do negócio) até à instalação da aplicação e, eventualmente, à manutenção. Olhar para DevOps development and operations como uma capacidade do próprio negócio desde a ideia ao produto faz da ALM parte do processo DevOps. Os cinco imperativos da ALM (jazz.net/library/article/637) aplicam-se a uma perspectiva da entrega de uma aplicação centrada em DevOps. Estes cinco imperativos são

• Planeamento em tempo eral
• Rastreabilidade do ciclo de desenvolvimento
• Colaboração in-context
• Sistema de Inteligência aplicada ao desenvolvimento
• Melhoria contínua dos processos

O planeamento em tempo real traduz-se pela adopção de um caminho de planeamento-e-medição.
A rastreabilidade e a colaboração traduzem-se pelo desenvolvimento-e-teste.
A Inteligência aplicada ao desenvolvimento e a melhoria contínua dos processos traduzem-se pela monitorização e optimização.

ALM pela Microsoft

Funcionalidades do Visual Studio para ALM

• Agile
• Backlogs
• Sprint backlogs
• Kanban boards
• Task boards

vide Agile Software Development

• Controlo de Versões
• Team Explorer (cliente TFS Team Foundation Server ou Git)

vide Version control

• Testes
• Testes unitários
• Testes de UI
• Testes de desempenho da web
• Testes de carga

vide Testing Tools

DevOps Version control Diagnostic tools Build Test Release Application Insights

Agile tools Plan and track work Scrum Kanban Track (queries) Dashboards and reports Feedback Customize

Setup and administration Install and setup Upgrade Administer

Métricas em destaque

A abordagem DevOps aumenta a agilidade por um lado e por outro, a confiabilidade:
Reduz o MTTD Mean Time To Detect
Dá uma visão completa do ecosistema da aplicação recorrendo a métricas que ajudam a identificar os constragimentos em produção. Minimiza assim os prejuizos e o impacto junto dos clientes.
Reduz o MTTR Mean Time To Repair
Permite detectar se o problema reside no código ou nas dependências. As ferramentas de gestão de incidentes integram Operações e Desenvolvimento. Os diagnósticos feitos em produção fornecem informação relevante ao desenvolvimento. Melhora a comunicação. Chega melhor informação aos clientes e aumenta a sua satisfação.

Do Desenvolvimento para as Operações

Microsoft Release Management

A principal função do Microsoft Release Management é a automa(tiza)ção do deploy do ambiente de testes para o de produção.
Para começar a trabalhar com a release há que:

• Identificar os ambientes de teste pelos quais a aplicação vai passar (ex: Dev-> QA-> Produção)
• Definir a sequência de acções necessárias à instalação da release em cada um dos ambientes
• Identificar os membros da equipa responsáveis por cada passo da instalação

Depois o deploy pode ser feito automaticamente. Um vez que o Microsoft Release Management está integrado com o TFS Team Foundation Server, o deploy da release pode ser efectuado imediatamente depois da build estar concluida no TFS.

Das Operações para o Desenvolvimento

Microsoft System Center 2012 Operations Manager

O Microsoft Operations Manager permite que várias aplicações sejam monitorizadas simultaneamente através da mesma consola e envia informação acerca dos eventos à equipa de desenvolvimento. Pode-se, portanto, monitorizar tanto aplicações web .Net como serviços Windows. São registadas as falhas e problemas de desempenho das aplicações tanto do lado do cliente com do lado do servidor.
Como está integrado com o TFS Team Foundation Server, esta informação pode ser assignada a um programador com apenas um clique. Uma vez enviada a informação do evento, é criado um Work Item no TFS com toda a informação necessária para a depuração do código.

Microsoft Monitoring Agent

É uma alternativa simples ao Microsoft Operations Manager. Esta ferramenta monitoriza localmente o desempenho das aplicações web .Net.
O Microsoft Monitoring Agent colecta dados apenas das aplicações instaladas localmente. Os dados recolhidos são gravados em ficheiro e podem ser enviados manualmente para a equipa de desenvolvimento.

Application Insights

Esta ferramenta está disponível como componente do Visual Studio Online . Esta componente permite:

• Monitorizar a disponibilidade e o tempo de resposta das aplicações web.
• Basta para isso especificar a URL Uniform Resource Locator e o Visual Studio executa os testes.
• Monitorizar o desempenho e a ocorrência de erros.
• O Microsoft Monitoring Agent está instalado no computador em que a aplicação a monitorizar está instalada e é ligado ao Application Insights. Depois disto a informação recolhida fica disponível no Application Insights.
• Analisar as acções do utilizador.
• Esta ferramenta regista todos os eventos que ocorrem na aplicação (ex: carregamento de um ecrã). Esta opção está disponível para os seguintes tipos de aplicação:
• Windows Phone 8
• Windows Store
• Web services
• Web pages

Microsoft Feedback Client

Através do Microsoft Feedback Client a equipa de desenvolvimento pode pedir e receber a opinião e crítica dos utilizadores sobre a aplicação em produção. O pedido é feito pela equipa através do TFS Team Foundation Server e enviado por email.
O utilizador recebe o pedido e com a ajuda do Microsoft Feedback Client instalado localmente cria uma revisão da sua interacção com a aplicação. Esta revisão pode conter vídeo, impressões de ecrã e audio além dos comentários.

Integração com outras ferramentas

Vm Depot, Jenkins, Chef, Puppet, New Relic através das Microsoft Open Tecnologies.

Referências

DevOps For Dummies®, IBM Limited Edition
Application Lifecycle Management
DevOps and Application Lifecycle Management

O termo "DevOps" geralmente refere-se ao movimento emergente de profissionais que defendem a existência de uma relação de trabalho colaborativo entre as áreas de Desenvolvimento e de Operações de TI, tendo como resultado um fluxo de trabalho planeado rápido (ou seja, com altas taxas de entrega/deploy), enquanto, ao mesmo tempo, aumenta a confiabilidade, a estabilidade, a resiliência e a segurança do ambiente de produção.

Por que razão Desenvolvimento e Operações de TI? Porque é, tipicamente, o fluxo de valor que está entre o negócio (que define os requisitos) e o cliente (a quem o valor é entregue). 

As origens do movimento DevOps surgem por volta de 2009, como convergência de vários movimentos adjacentes que se complementam:

• O movimento resultante da "Velocity Conference", em especial da apresentação "10 Deploys A Day" dada John Allspaw e Paul Hammon
• O movimento  "infrastructure as code" (Mark Burgess e Luke Kanies), o movimento "Agile infrastructure"(Andrew Shafer) e o movimento "Agile system administration" (Patrick DeBois)
• O movimento Lean Startup de Eric Ries
• O movimento "continuous integration and release" de Jez Humble
• A disponibilização generalizada das tecnologias da Nuvem e dos serviços PaaS (platform as a service) como é o caso do serviço Amazon Web Services.

~Gene Kim