SDLC e cenas e coisa e tal - Bruno Lopes & C. Augusto Proiete

Software Development Lifecycle e cenas e coisa e tal
Por C. Augusto Proiete & Bruno Lopes

Esta sessão abordará alguns dos desafios comuns que encontramos nas diversas fases do desenvolvimento de software, à medida que os projectos, equipas, e/ou empresas amadurecem.

Vamos falar sobre diferentes tópicos relacionados com o ciclo de desenvolvimento de software, incluindo: Organização de repositórios em source control, estratégias de versionamento de software, branching, integração contínua, partilha e distribuição de código, deployment de aplicações, suporte e rastreabilidade, entre outras coisas.

O principal objectivo é discutir algumas práticas conhecidas em cada desafio, utilizando uma série ferramentas integradas, de forma a demonstrar diferentes cenários.

Vídeo desta apresentação:
https://www.youtube.com/watch?v=-I4Nx5Ol5Kk

Transcript

1. http://netponto.org 67ª Reunião Presencial - 25/02/2017 SDLC e cenas e coisa e tal Bruno Lopes & Caio Proiete
2. Agenda
3. Agenda •Controlo de Versão •Partilha de Código / Modularidade •Builds Automatizadas •Deployments Automatizados •Rastreabilidade
4. Intro – Bruno • Dev/Support Produto Web SaaS • Equipa pequena e “full stack” • Distribuídos entre Lisboa e Porto • Uma app, várias instalações, vários clientes
5. Intro – Bruno HTML (JS, Knockout) Web app (ServiceStack) RavenDB PostgreSQL Redis
6. Intro – Caio • Responsável técnico em múltiplos projectos • Equipa razoavelmente grande, com especializações • Equipa distribuída entre Bermuda, UK, e USA • Várias apps, uma instalação (duas no máximo), clientes internos (grande maioria)
7. Intro – Caio • Multiplos UIs • APIs Públicas e Privadas • Multiplos Serviços • Análises Computacionais • Simulações de Cenários • Versionamento de Dados • Tranformações de Dados • Busca & Indexação • Event Hubs • Data Warehouse
8. Zen Deployments automatizados Builds automatizadas Controlo de Versões “Works on my machine”
9. Pipeline Bruno & Caio Promote Package Test Build Artifact Repository Version Control Deploy Configure Test Acceptance Production
10. Partilha de Código / Modularidade nuget push https://nuget.netponto.org
11. Partilha de Código / Modularidade • Git Submodules é fixe, mas é difícil de entender, fácil de perder código • Quanto maior a equipa, mais dor de cabeça (YMMV) • Único sítio em que tenho isto a funcionar bem, é automatizado no build server, para correr ”sanity checks” • SanityCheck repo = ProjectoA (submodule) + ProjectoB (submodule) + ProjectoC (submodule) + ...
12. Partilha de Código / Modularidade • NuGet All Things (!) • Precisa dizer mais alguma coisa? • NuGetizer 3000 !!!!!
13. Controlo de Versões git pull origin netponto-comunidade
14. Controlo de Versões – Bruno • Um só repo, duas soluções (.sln), ~10 projectos • Tudo released em conjunto • Um dos componentes (plugins ravendb server-side) está “completo” e podia ser um package nuget
15. Controlo de Versões – Caio • Múltiplos repositórios, ~130 no total • Uma solução (.sln) por repositório • Inúmeros projectos (.csproj) por repositório entre 2 a 105 • Muitos repositórios partilhados (distribuídos via NuGet) • Diversas tecnologias UI (WPF, WinForms, Excel-DNA, ASP .NET MVC) • Dezenas de Windows Services (WebAPI, Akka.NET, SignalR, Matlab) • Releases independentes, por grupos de componentes
16. Controlo de Versões – Caio • A estrutura de repositórios de um projecto simples parece-se mais ou menos com isto:
17. Controlo de Versões – Bruno – Branching master (90% directo em master) develop (ocasionalmente) Branch per feature ICAST-####-ShortDescription ICAST-ShortDescriptionForNoTicket Feature flags • Algumas features ainda não estão prontas para o mundo
18. Controlo de Versões – Caio – Branching master (produção / pré-produção) develop (integração) bugfix/initials-####-description feature/initials-####-description hotfix/initials-####-description release/yyyy-MM-dd Feature flags – Sempre que possível
19. Builds Automatizadas msbuild NetPontoApp.sln /t:Build /p:RunOctoPack=true
20. Builds Automatizadas – Caio • Pelo menos 1 TeamCity build para cada repositorio Git • Mesma TeamCity build para todas as branches • Inclui simulação de merge de pull-requests também • Diversos build templates • Quase todas as builds ”herdam” características de um build template • Diversos ”meta-runners” (a.k.a. step templates) reutilizáveis • Pelo menos 2 triggers: Source Control push & Schedule (nightly) • Evolução das builds via clone temporário até o próximo release
21. Builds – Caio • A estrutura de builds de um projecto simples parece-se mais ou menos com isto: • Lembra? Pelo menos 1 build para cada repositorio Git
22. Builds – Steps (maioria das builds) – Caio 1. Determine build version number 2. Build (MSBuild) (Release) 3. Run Static Analyzers (ReSharper, StyleCop, etc.) 4. Run Tests (Unit, Integration, Specification) (NUnit) 5. Package build artifacts into deployable artifacts (Release) 6. Build (MSBuild) Debug mode 7. Package build artifacts into deployable artifacts (Debug) 8. Ship artifacts to artifacts repository (Nexus) 9. Tag source control with build version number
23. Builds – Steps (maioria das builds) – Bruno Compile Test • Source sanity • Unit/Integration • Specification Push to Octopus Deploy to test Deploy to ……. Nugets Nugets Nugets
24. Builds – Versioning • Semantic Versioning (SemVer) - Caio • Major.Minor.Patch (master branch) • exemplo: 2.7.1934 • Major.Minor.Patch-BranchName (outros branches) • exemplo: 2.7.1934-feature-cp-NP-123-lo • Major & Minor em source control (~/version.txt) - Caio • Patch gerado automaticamente pelo TeamCity (auto-increment) • TeamCity actualiza AssemblyInfo.cs de todos os projectos
25. Builds – Agents – Caio • 1 build agent para cada CPU/vCPU que a máquina possui • Dependencias em ferramentas via NuGet sempre que possível • Manter o ambiente o mais ”clean” possível • Não instalar Visual Studio em nenhum dos agentes (só mesmo em último caso) • O mesmo vale para outras IDEs (ex. Matlab, RStudio, IntelliJ, etc...) • Instalar SDKs = OK, Instalar Emuladores = OK (se via NuGet não dá) • Bastante espaço em disco para guardar artefactos por muito tempo
26. Deployments Automatizados octo --deploy-release –-deployto=Production --force
27. Deployment • A estrutura de deployment de um projecto simples parece-se mais ou menos com isto:
29. Deployment • Exemplo de deploy de web app • Neste momento existe setup e update - Bruno • Setup • cria app pool/websites IIS • cria bases de dados e corre migrações • configura certificados SSL • inicializa configuração da aplicação • copia ficheiros websites • Update • faz backups • corre migrações • copia ficheiros websites • O caminho seria para apenas haver uma “declaração de estado"
30. Migrações • Idealmente idempotentes • Caso dê problema, correr de novo • Write-once, change-never • Sempre em frente • Faltou algo na migração que está no master? Cria uma nova a seguir
31. Rastreabilidade Vamos falar rapidamente sobre rastreabilidade
32. De onde veio este assembly? .NET Built-in: [AssemblyInformationalVersionAttribute("1.0.42-develop")] Personalizados: [AssemblyBuildBranchNameAttribute("develop")] [AssemblyBuildCommitHashAttribute("de39047")] [AssemblyBuildTimeStampAttribute("2017-02-25 10:18:49")] [AssemblyBuildVersionAttribute("1.0.42-develop@de39047")] /api/admin/diagnostics mostra versão, e mais alguns dados
33. De onde veio este assembly? Assembly Branch Source Control Commit Source Control Release Ticket Release Tag Source Control TeamCity Build Octopus Release # Quem fez o Release Testes Executados Code Coverage Story Ticket
34. Serilog & Semantic Logging – Caio • Logging estruturado. Mensagens do log são mais do que ”texto” • Mensagens podem ter propriedades que podemos consultar (query) // Bibliotecas de logging tradicionais log.Error(string.Format("User launched unsupported {0} of {1}", version, name)); // Serilog log.Error("User launched unsupported {version} of {appName}", version, name);
35. Logging Centralizado – Caio • Serilog everywhere, envia tudo para um servidor a correr Seq
36. Logging Centralizado – Bruno • Exceptionless a beber de vários sitios
37. Agora tudo junto... Vamos lá rever a pipeline com as ferramentas todas
38. Pipeline Promote Package Test Build Artifact Repository Version Control Deploy Configure Test Acceptance Production
39. Pipeline & Tools Test Acceptance Production Promote Package Test Build Artifact Repository Version Control Deploy Configure Git (Open-source) BitBucket Server (Atlassian) / GitHub TeamCity (JetBrains) Nexus (Sonatype) / Teamcity / Octopus NuGet (Open-source, Microsoft) OctopusDeploy (OctopusDeploy)
40. (mais) Questões? :)
41. Links (1/5) • OctopusDeploy • https://octopus.com • BuildMaster • https://inedo.com/buildmaster • CodeShip • https://codeship.com • Ansible • https://www.ansible.com
42. Links (2/5) • TeamCity • https://www.jetbrains.com/teamcity/ • Jenkins • https://jenkins.io • AppVeyor • https://www.appveyor.com • TravisCI • https://travis-ci.org
43. Links (3/5) • Git • https://git-scm.com • GitHub • https://github.com • BitBucket • https://bitbucket.org • GitLab • https://gitlab.com
44. Links (4/5) • Nexus • http://www.sonatype.org/nexus/ • MyGet • https://www.myget.org • ProGet (?) • https://inedo.com/proget • NuGet.Server • https://www.nuget.org/packages/NuGet.Server/
45. Links (5/5) • Serilog • https://serilog.net • Seq • https://getseq.net • Exceptionless • https://exceptionless.com
46. Bruno Lopes – brunomlopes@netponto.org - @brunomlopes Caio Proiete – caio@netponto.org - @caioproiete Obrigado!
47. Patrocinadores “GOLD” Twitter: @PTMicrosoft http://www.microsoft.com/portugal
48. Patrocinadores “Silver”
49. Patrocinadores “Bronze”
50. http://bit.ly/netponto-aval-67 * Para quem não puder preencher durante a reunião, iremos enviar um email com o link à tarde
51. Próximas reuniões presenciais 25/02/2017 – Lisboa 04/03/2017 – Porto 25/03/2017 – Lisboa 29/04/2017 – Lisboa 27/05/2017 – Lisboa Reserva estes dias na agenda! :)
52. Bruno Lopes – brunomlopes@netponto.org - @brunomlopes Caio Proiete – caio@netponto.org - @caioproiete Obrigado!