segunda-feira, 13 de julho de 2009

TFS 2008 no Windows 2008 com o SQL Server 2008 – DETONADO!

Se você gosta de desafios, tente fazer o seguinte: Instale o TFS 2008 (Team Foundation Server) em um Windows Server 2008 com o SQL Server 2008. É uma experiência única, pela qual todo desenvolvedor .NET deveria passar. A sensação de completar essa tarefa é a mesma que se tem ao chegar no final do God of War, ou do Assassins Creed. Impagável!

Escolha o Nível de dificuldade:

Primeiro defina o ambiente que você quer instalar. Você pode optar pelo Single-Server, onde todos os recursos são instalados no mesmo servidor. Ou o Dual-Server, onde temos um servidor de Dados (SQL Server 2008), e um servidor de aplicação (TFS e seus recursos). Você ainda pode optar por uma instalação “Multi-Server”, onde além do servidor de aplicação temos um servidor de Build e outro de Proxy. Esse é o nível mais alto de dificuldade, e não aconselhável para iniciantes.

Fase 1: Domínio ou Workgroup?

Você vai instalar o servidor TFS em uma rede com domínio ou em um WorkGroup? Decida isso antes de prosseguir. No caso de uma rede com domínio, o TFS não pode ser instalado no Domain Control (é claro).

Fase 2: 64-bits com Hyper-V?

O TFS 2008 NÃO pode ser instalado em um Windows Server 2008 64-bits. Se seu servidor é x64, a sugestão é instalar um Windows Server 2008 x64 nele, e habilitar o Hyper-V (Servidor de virtualização que vem no 2008). No Hyper-V você cria uma VM com Windows Server 2008 32-bits, e nele sim você instala o TFS.

Dica 1: O Hyper-V só pode ser instalado se seu hardware atender a determinados requisitos. Use este software para verificá-los.

Dica 2: Para instalar um Windows Server 2008 86x em uma VM do Hyper-V, utilize a edição classificada como “Without Hiper-V”.

Fase 3: Application e Web Roles

Com o Windows Server 2008 32-bits instalado para o TFS, habilite as Roles Application Server e Web Server (IIS). Além disso, coloque seu servidor na rede, é claro. Se estiver no Hyper-V você deve usar uma rede de conexão externa. E se sua rede tiver um DC, coloca o servidor no domínio. Feito isso, Windows Update nele!

Fase 4: Criando os Usuários do TFS

Você deve basicamente criar dois usuários. Um chamado TFSSETUP que será usado para a instalação. E outro chamado TFSSERVICE, que será usado para os serviços. Ambos podem ter nomes diferentes, e você pode opcionalmente criar uma conta de serviço para cada um dos demais serviços do TFS, como TFSREPORTS e TFSPROXY. Mas o TFSSERVICE sozinho dá conta do recado, principalmente em um Single-Server.

Se você está em uma rede com domínio, estes usuários precisam ser criados no Active Directory do seu DC, senão eles devem ser criados como usuários do próprio servidor. O TFSSETUP precisa estar no grupo de Administradores Locais do Servidor TFS (não do domínio). E o TFSSERVICE (e de demais contas de serviço) precisam ter a permissão para se logar como um serviço, no servidor TFS. Você faz isso através dos seguintes passos: Administrative Tools / Local Security Policy / Local Policies / User Rights Assignments / Log on as a service.

Faça um log-off, e a partir daqui utilize o TFSSETUP para as demais operações.

Fase 5: SQL Server 2008

Esse é dureza, e grande parte do truque está aqui. Você não pode instalar o SQL Server 2008 com o Service Pack 1, e nem aplicar o Service Pack 1 após a instalação! O TFS não vai reconhecer o SQL 2008 SP1 como um servidor de dados válido, portanto faça a instalação apenas do SQL 2008. Além disso, você deve utilizar a edição Standard ou Enterprise, nunca a Express. Uma dica é ter um SQL Server 2008 dedicado ao TFS.

Faça uma instalação completa do SQL Server 2008, sem dó. Reporting, Analysis, Full Text Search, etc. O TFS vai precisar de tudo isso. Utilize o TFSSERVICE para os serviços que o SQL Sever solicitar um usuário. Pode ser o mesmo para todos, não tem problema. Instale o SQL Server apenas com o Windows Authentication Mode, e defina o TFSSETUP como um dos administradores.

Fase 6: Verificar o SQL Server 2008

Após a instalação e um reboot, vá ao SQL Server Configuration e defina todos os serviços como “Iniciados” e “Inicialização Automática”. E certifique-se de que o TCP esteja habilitado. Abra o Management Studio e tente se conectar no Database Engine. Se a conexão estiver ok, passe para a fase seguinte.

Fase 7: Sahrepoint

O TFS precisa do SharePoint, seja o Windows SharePoint Services (WSS que é parte do Windows Server), ou do MOSS 2007 (Microsoft Office Sharepoint Server, também conhecido como Sharepoint Products and Tecnologies). O WSS pode ser instalado e configurado pelo próprio instalador do TFS. Já o MOSS 2007 precisa ser instalado antes. Você pode instalá-lo no mesmo servidor do TFS ou em um outro servidor. No meu caso eu instalei o MOSS 2007 no mesmo servidor do TFS, logo após a instalação do SQL Server 2008. Seguem os passos da instalação do MOSS:

Passo 1: Execute o instalador e na primeira tela escolha o tipo de instalação AVANÇADA.

Passo 2: Em Server Type escolha a opção COMPLETE.

Passo 3: Ao pedir para reiniciar os serviços, clique em YES.

Passo 4: Na Janela “Connect to Server Farm” escolha a opção “No, I want to create a new server farm”.

Passo 5: Em “Specify configuration Database Settings”, informe o nome do servidor TFS no “Database Server”, mantenha o nome padrão para o “Database name”, e em “Specify Database Access Account” escolha o usuário TFSSERVICE.

Passo 6: Na janela "Configure SharePoint Central Administration Web Application", escolha um número de porta para a Central de Administração do Sharepoint, e guarde este número. E em “Configure Security Settings” escolha NTLM

Passo 7: Ao término da instalação do Sharepoint, abra o prompt de comando como administrador (run as adminstrator). Vá até a pasta: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin\ e execute o seguinte comando:

stsadm.exe -o extendvs -exclusivelyusentlm -url http://WSSServerName:80 -ownerlogin Domain\TFSSERVICE –owneremail "admin@localhost" -sitetemplate sts -description "Default Web Site".

Substituindo o “WSSServerName” pelo nome do seu servidor, e o “Domain” pelo nome do seu domínio.

Passo 8: Ainda no prompt de comando, execute mais esse:

stsadm.exe -o siteowner -url http://WSSServerName:80 -secondarylogin Domain\TFSSETUP

Passo 9: Para finalizar a configuração do MOSS2007 você ainda deve ir na central de administração e configurar todos os serviços para iniciarem automaticamente. Siga as prórprias orientações nas tasks da Central de Administração do Sharepoint. Assim que finalizar tudo, faça um reboot no servidor.

Fase 8: Aplicando o Service Pack 1 no instalador do TFS 2008

Você chegou na fase mais difícil. Se passar por aqui está com o jogo ganho. Como disse antes, o TFS 2008 não reconhece o SQL2008 SP1, mas ele também não reconhece o SQL2008 (sem o SP1). Porém, o SP1 do TFS, esse sim reconhece o SQL2008 (sem o SP1). Mas não existe uma instalação do TFS com o SP1. Muita gente morre aqui e usa o SQL 2005 mesmo.

O truque é aplicar o SP1 do TFS no Setup, antes da instalação. Sim isso é possível. Exige uma certa destreza mas dá pra fazer. Siga exatamente estes passos:

Passo 1: Faça o Download do SP1 do TFS, e salve-o em uma pasta chamada C:\SP1Download

Passo 2: Abra o DVD de instalação do TFS e salve o conteúdo da pasta AT na pasta C:\InstallMedia

Passo 3: Abra o Prompt de Comando como administrador (run as administrator) e execute o seguinte comando: C:\SP1Download\TFS90SP1-KB949786-ENU /extract:C:\SP1Extract

Passo 4: Crie uma pasta chamada C:\MergeFolder

Passo 5: Ainda no prompt de comando execute: msiexec /a C:\InstallMedia\vs_setup.msi /p C:\SP1Extract\TFS90sp1-KB949786.msp TARGETDIR=C:\MergeFolder

Passo 6: na pasta C:\MergeFolder teremos o Setup do TFS com o SP1 já aplicado a ele. Se você chegou até aqui, execute o "Setup.msi" e seja bem vindo a fase nove.

Fase 9: Instalando o TFS

Passo 1: Aceite os termos de licença. (aquele que chegar até aqui e não aceitar os termos de licença será amaldiçoado pela eternidade)

Passo 2: Em Destination Folder pode aceitar o padrão e seguir com Next.

Passo 3: Em "Team Foundation Database Server", indique o nome do servidor do banco de dados.

Passo 4: Em "System Health Check" o setup vai verificar se todos os pré-requisitos estão ok. Caso haja algum problema, é sinal de que você não completou corretamente alguma coisa nas fases anteriores. Neste caso, é um jogo de paciência onde você terá que identificar o problema e repetir alguns passos feitos anteriormente. Use o Guia Oficial de Instalação do TFS para identificar o problema e tomar as ações necessárias. Caso todos os pré-requisitos estejam ok, você poderá continuar com a instalação.

Passo 5: Em "Team Foundation Server Service Account" use o TFSSERVICE.

Passo 6: Em "Reporting Services Data Source Account" use o TFSSERVICE.

Passo 7: Em "Windows SharePoint Services Service Account" selecione "Use Team Foundation Server service account".

Passo 8: Em "Specify Alert Settings" opcionalmente habilite os alertas e defina o servidor SMTP. (opcional)

Passo 9: Inicie e aguarde o término da instalação.

Fase 10: Team Explorer

Instale o Team Explorer nos computadores de desenvolvimento da sua rede, que já tenham o Visual Studio 2008 (Standard, Enterprise ou TeamSystem) instalado. A versão Express é incompatível com o TFS. Instale o Team Explorer no Servidor também, pode parecer sem sentido, mas ele é pré-requisitos para pacotes como o Srcum Process Template da Conchango

É isso aí! Esses foram os passos que eu segui para detonar o TFS2008 no Windows2008 com o SQLServer2008. Agora com tudo já instalado você pode aplicar o SP1 do SQLServer2008, sem problemas.

São muitas as variáveis que envolvem a instalação deste ambiente, e por isso você pode chegar ao mesmo resultado de formas variadas. Caso você tenha alguma dica, ou tenha passado por algumas dessas fases de uma maneira diferente, deixe seu comentário aqui.

Grande Abraço e até a próxima!

quinta-feira, 25 de junho de 2009

Qual é a sua Meta?

Nunca fui fã de livros de administração. Não gosto daqueles textos enfadonhos que, ou falam o óbvio, ou alguma coisa que nunca entenderei direito. Mas tem um livro muito famoso que estava na minha lista há tempos: “A META” de Eliyahu M. Goldratt e Jeff Cox.

Sabe aqueles livros que todo mundo fala que você tem que ler, mas que você fica com um pé atrás, achando que vai se arrepender? Deste eu não me arrependo não. Ele não é bom só porque aborda gerencia e administração através de um Romance, com ele eu aprendi coisas realmente interessantes. E é perfeitamente possível traçar um paralelo entre os problemas tratados na história do livro (que foca uma indústria), com problemas de empresas de desenvolvimento de Software.

Vamos a um breve resumo para eu iniciar meu raciocínio: A Meta conta a história de Alex Rogo, um gerente de uma fábrica de uma cidadezinha do interior dos EUA. A Fábrica está literalmente numa pior, com muitos pedidos atrasados, clientes reclamando, problemas vindos de todos os lados, pressão de diretores, e por aí vai. Alex tem três meses para reverter a situação, senão a fábrica fecha. E para piorar um pouco, a mulher está a ponto de abandoná-lo, pois ele não tem mais tempo para a família.

A história começa apresentando este cenário, e vai mostrando como o Alex vai conseguindo conquistar melhorias, tanto na vida profissional, quanto na pessoal, com a ajuda de um velho conhecido chamado Jonah.

A partir daí, se você se interessou, sugiro que leia o livro. Vale à pena, pode acreditar. Abaixo vou acabar colocando alguns spoilers, mas nada que inviabilize a leitura. (mesmo assim, se você não quiser saber mais detalhes da história, pare de ler por aqui).

A primeira tarefa do Alex para sair do buraco é descobrir qual é a verdadeira META da sua fábrica, ou melhor: Qual é a verdadeira meta de qualquer organização?

No começo eu achei essa questão muito óbvia, e não entendia porque o Alex demorou e sofreu tanto para achar a resposta. Até que eu refiz essa pergunta da seguinte forma: Qual é a META de um departamento de desenvolvimento de software?

Aí eu entendi a dificuldade. Pare aí um minuto para pensar, você que trabalha com desenvolvimento de software. Qual é a verdadeira META que a sua empresa, ou o seu departamento deve seguir?

As respostas mais comuns são:

- Criar software de qualidade;
- Atender às necessidades dos usuários;
- Cumprir os Requisitos no prazo combinado;
- Fazer Software para Durar (essa é a preferida dos Arquitetos);
- Criar Software reutilizável;
- Zero Bug! (preferida dos adeptos do TDD);
- Entregar um produto de qualidade, que agregue valor e sinergia aos processos de negócio dos nossos clientes (é sério, tem gente que fala desse jeito);
- etc.

Enfim, nenhuma dessas é a resposta correta. A verdadeira META de uma empresa é GANHAR DINHEIRO! É óbvio, e provavelmente você já chegou a essa resposta lá atrás.

Mas e quando falamos especificamente de um departamento de desenvolvimento de software, de uma empresa que não comercializa software? A resposta é a mesma. Se a Meta de qualquer empresa é o Ganho, todos os departamentos dessa empresa devem seguir a Meta. Ou seja, o software que fazemos, direta ou indiretamente, deve levar a organização em direção ao Ganho. Pense um pouco, o software que o seu departamento faz, ajuda a empresa a alcançar sua Meta? Direta ou indiretamente é o que deveria acontecer.

O fato é que quando estamos muito envolvidos nos processos operacionais do nosso trabalho, é difícil enxergar que tudo o que fazemos, no final das contas tem o único objetivo de se converter em Dinheiro.

E se a META de uma organização é ganhar DINHEIRO, a produtividade dessa organização só pode ser medida com relação a este GANHO.

Então, a próxima pergunta que eu lhe faço é: Você, como desenvolvedor de software, é produtivo com relação à META da sua empresa? As tarefas que você executa diariamente estão especificadas e priorizadas para atender a verdadeira META da organização onde você trabalha?

Essa visão pode parecer capitalista demais, mas é assim que as coisas funcionam. O primeiro passo para sermos mais produtivos, é admitir qual é a verdadeira META do nosso Trabalho.

É claro que não para por aí. Essa foi a primeira lição que o Alex aprendeu na história. Existem muitas outras questões que aprimoram e evoluem essa idéia, e o livro trata delas de uma forma muito ilustrativa, sempre deixando uma questão no ar: Será que estamos no caminho certo?

Na media do possível vou tentar explorar mais sobre essas questões aqui neste Blog. A Teoria das Restrições (TOC – Theory of Constraints), com o processo de melhoria contínua, é particularmente interessante, e podemos aplicá-la no desenvolvimento de software. Mas se você não quiser esperar meu próximo post, leia o livro!

Agora, se você faz software e não ganha dinheiro (direta ou indiretamente), você provavelmente possuí outro emprego e software é apenas um hobby, já é milionário e não sabe o que fazer com o tempo livre, é sustentado pelos seus pais ou cônjuge, ou mora num país verdadeiramente comunista. :)

Grande Abraço e até a próxima!

quarta-feira, 3 de junho de 2009

CRUD no ADO.NET

Nós que trabalhamos na borda da tecnologia, sempre procurando por novidades, avaliando versões betas, ctps, etc, acabamos esquecendo um pouco das coisas simples e básicas. Notei isso recentemente quando algumas pessoas que estão começando a aprender C# me pediram por um exemplo simples de rotinas de inclusão, alteração, exclusão e consulta de registros em uma tabela de um banco de dados SQL Server. Me assustei quando notei que não tinha tal exemplo pronto, para poder enviar.

É em nome da simplicidade, e para que sempre que possível, possa ajudar quem tem interesse em aprender C#, que vou começar a postar aqui alguns exemplos e conceitos básicos. Começando hoje com um exemplo de CRUD, usando os recursos mais simples do ADO.NET.

Para quem não é familiarizado com a sigla, CRUD é o acrônimo de: Create, Read, Update e Delete. Referencia às quatro operações básicas de qualquer banco de dados.

O código deste exemplo que vou mostrar aqui, pode ser executado em um aplicação do tipo Console Application, e precisa do database Northwind da Microsoft. É claro que você deve adaptá-lo para que funcione no seu banco de dados e no tipo de aplicação que deseja: ASP.NET, Windows Forms, WPF, Silverlight, etc.

Comecemos então com o código necessário para abrir a conexão com o banco de dados. Veja na Listagem abaixo:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using System.Data;
using System.Data.SqlClient;

namespace Algorama.Exemplos.CRUDSimples.AppConsole
{
class Program
{
static void Main(string[] args)
{
string ConnString =
"Data Source=(local);Initial Catalog=Northwind; Integrated Security=True";
SqlConnection Conn = new SqlConnection(ConnString);
try
{
Conn.Open();
InsertShippers(Conn, "ALGOARAMA", "123456");
//UpdateShippers(Conn, "ALGORAMA - ALTERADO", "55555555", 4);
//DeleteShippers(Conn, 4);
SelectShippers(Conn);
Console.ReadKey(); }
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
Console.ReadKey();
}
finally
{
Conn.Close();
}
}
}
}

Note nas linhas 6 e 7, que precisamos importar os namespaces System.Data e System.Data.SqlClient, para que possamos utilizar os recursos do ADO.NET para SQL Server. Em seguida dentro do método Main (que é executado quando rodamos uma aplicação console), veja que estamos criando um objeto da classe SqlConnection (linha 17), através de uma ConnectionString (linha 16), que possuí as credenciais para acessar o banco de dados no servidor.

Quando vamos abrir uma conexão com um banco de dados, precisamos garantir que o nosso código vá fechá-la corretamente, depois de usada. É por isso que usamos a estrutura try/catch/finally. Com ela, mesmo que ocorra um erro durante o acesso ao banco, estamos garantindo que a linha 33 sempre será executada, fechando a conexão.

Depois que abrimos a conexão com o banco, na linha 20, note que temos a chamada de 4 métodos. Esses são os métodos correspondentes às quatro operações CRUD. Alguns estão comentados, pois para efeito de testes, é interessante que você execute um por vez. Vamos então ao código de cada um destes métodos, a começar pelo Insert.

private static void InsertShippers(
SqlConnection Conn,
string Name, string Phone)
{
SqlCommand Comm = new SqlCommand();

Comm.CommandText =
"INSERT INTO Shippers( CompanyName, Phone ) Values(@Name, @Phone)";
Comm.Parameters.Add(new SqlParameter("@Name", Name));
Comm.Parameters.Add(new SqlParameter("@Phone", Phone));

Comm.CommandType = CommandType.Text;
Comm.Connection = Conn;

int nroReg = Comm.ExecuteNonQuery();

Console.WriteLine(
"{0} Registro(s) Inserido(s)",
nroReg.ToString());
}

Todos os quatro métodos recebem como parâmetro o objeto de conexão aberto no método Main. Com este objeto, no método Insert podemos criar um objeto da classe SqlCommand (linha 5), e definir um comando no formato texto (linha 7). É claro que você poderia estar usando uma stored procedure aqui.

Veja que nas linhas 9 e 10, estamos alimentando os parâmetros do comando que será executado. Essa prática garante que nossa aplicação esteja segura quanto a possíveis ataques de SQL Injection. Por fim o comando é executado e uma mensagem exibida na console.

Note que para que você utilize essa rotina em uma aplicação Windows Forms ou ASP.NET, poucas adaptações devem ser feitas. A essência da operação de inclusão não muda.

O próximo método que segue na Listagem abaixo, é o método que faz a operação de Select. Veja que também usamos um SqlCommand, porém, neste caso o SqlCommand é executado por um SqlDataAdapter (linha 11), que é usado para preencher um DataSet (linha 13).

private static void SelectShippers(
SqlConnection Conn)
{
SqlCommand Comm = new SqlCommand();

Comm.CommandText = "SELECT * FROM Shippers";
Comm.CommandType = CommandType.Text;
Comm.Connection = Conn;

DataSet ds = new DataSet();
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = Comm;
da.Fill(ds);

Console.WriteLine(
"Total de: {0} registros",
ds.Tables[0].Rows.Count);

foreach (DataRow item in ds.Tables[0].Rows)
{
Console.WriteLine(
"Id: {0} - Name: {1} - Phone: {2}",
item["ShipperID"],
item["CompanyName"],
item["Phone"]);
}
}

O dataset é uma representação em memória de parte do nosso banco de dados. Com ele podemos recuperar e manipular os dados do database de forma desconectada. Esse é um assunto a parte, que deve ser explorado em mais detalhes em outra ocasião.

Por fim, ainda no método Select, depois de recuperados todos os registros, estamos imprimindo-os na Console através de um foreach (linha 19), que irá percorrer por todas as linhas da tabela do nosso dataset.

Por último, temos agora os métodos de Update e Delete, que seguem nas próximas duas listagens. Eles tem comportamento muito parecido com o Insert, que usa o SqlCommand e parâmetros, dispensando qualquer comentário adicional.

private static void UpdateShippers(
SqlConnection Conn,
string Name, string Phone, int ID)
{
SqlCommand Comm = new SqlCommand();

Comm.CommandText =
"UPDATE Shippers SET CompanyName = @Name, Phone = @Phone WHERE ShipperID = @ID";
Comm.Parameters.Add(new SqlParameter("@Name", Name));
Comm.Parameters.Add(new SqlParameter("@Phone", Phone));
Comm.Parameters.Add(new SqlParameter("@ID", ID));

Comm.CommandType = CommandType.Text;
Comm.Connection = Conn;

int nroReg = Comm.ExecuteNonQuery();

Console.WriteLine(
"{0} Registro(s) Alterados(s)",
nroReg.ToString());
}

private static void DeleteShippers(
SqlConnection Conn, int ID)
{
SqlCommand Comm = new SqlCommand();

Comm.CommandText = "DELETE FROM Shippers WHERE ShipperID = @ID";
Comm.Parameters.Add(new SqlParameter("@ID", ID));

Comm.CommandType = CommandType.Text;
Comm.Connection = Conn;

int nroReg = Comm.ExecuteNonQuery();

Console.WriteLine(
"{0} Registro(s) Deletados(s)",
nroReg.ToString());
}

É importante notar que o código apresentado aqui serve como teste para estas quatro operações. Se você pretende usar este código em uma aplicação Windows ou Web, terá que realizar algumas adaptações. Se você quiser, pode ainda fazer o download desse exemplo aqui.

Espero que este post ajude quem procura por um exemplo básico de ADO.NET.
Grande Abraço e até a próxima!