Continuous Integration, Continuous Delivery e Jenkins

Transcript

1. Continuous Integration, Continuous Delivery
2. Bacharel em Ciência da Computação pela FURB Programador e Líder de equipe na Bludata Twitter: @jaswdr Github: github.com/jaschweder E-mail: jonathanschweder@gmail.com Hackerspace: hackerspaceblumenau.slack.com Jonathan A. Schweder
3. Como desenvolvemos software ?
4. Requisito Desenvolvimento Entrega
6. Como posso evitar falhas ?
8. Esteja preparado para o problema!
9. Foco em minimizar falhas!
10. Continuous Integration
11. Continuous Integration “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily” Martin Fowler
14. Continuous Integration “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily” Martin Fowler
15. Practices of Continuous Integration Maintain a Single Source Repository Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Fix Broken Builds Immediately Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment
16. Algumas alternativas de CI
17. Continuous Delivery
18. Continuous Delivery “Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” Martin Fowler
19. You’re doing continuous delivery when: • Your software is deployable throughout its lifecycle • Your team prioritizes keeping the software deployable over working on new features • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them • You can perform push-button deployments of any version of the software to any environment on demand
20. • Reduced Deployment Risk: since you are deploying smaller changes, there's less to go wrong and it's easier to fix should a problem appear. Advantages
21. • Believable Progress: many folks track progress by tracking work done. If "done" means "developers declare it to be done" that's much less believable than if it's deployed into a production (or production-like) environment. Advantages
22. • User Feedback: the biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is (particularly if you use Advantages Every Commit Should Build the Mainline on an Integration Machine
25. Dúvidas ?
26. Fim Fim