No fear to tame the automatic deploys

You’ve may heard of CI/CD, which stands for Continuous Integration and Continuous Delivery. Both relate to broader topic which is DevOps — a set of practices that’s the main goal is to create and release software in smaller pieces, faster and more reliably, to make release of the software fast. And such can be reached by automating its building process. To achieve it CI/CD practice can be introduced which covers frequently commits to the main application branch, testing it and then releasing it.

Transcript

1. No fear to tame the automatic Deploys Jackson Mafra | Android Developer @ DevGrid
2. Hello, I'm Jackson Mafra Developer for over 20 years with a background in e-commerce and real estate projects, since 2009 focused on the development of mobile interfaces and corporate applications. @jacksonfdam
3. Where do I work... is a Full Stack software development company based in the United Kingdom with two delivery hubs in Brazil. We enable innovation and digital transformation by bringing together our strong company culture and our bright engineers with your innovative business vision.
4. I. Introduction Integration, Delivery and Continuous Deployment Deploys and Pipelines Tools, Providers II. Conclusions III. Topics
5. Introduction! Rapid whole fucking vision. I.
6. In small projects, developers can do tasks manually with regards to building projects, testing, and deployment. When the project grows exponentially it will become a big headache. The problem
7. The Project
8. Firebase - Apps
9. Firebase - Apps distribution
10. Google Play Console - Releases
11. Automate more, so you do less.
12. Introduction Why we need Continuous Integration ( CI ), Continuous Delivery ( CD ), Continuous Deployment ( CD )? Continuous Integration (CI) is the process of automating the build every time a team member commits changes to version control.
13. Introduction In this phase mostly we have integration tests, functional tests, and acceptance tests.
14. Introduction After that we have artifacts. This means a runnable product which is saved in someplace. In our case, we will save our APK as an artifact with the proper versioning system. Up to this point if everything is good we can send this deliverable to our QA team for testing by using Email or any service with release notes.
15. Introduction There are plenty of continuous integration platforms, some you can set up on your own machine while the other offer cloud-based solutions. This several tools that can help us, developers, automate all this stuff. One of the most popular are Jenkins, GitLab, Travis CI, CircleCI, or TeamCity. And lately, a new-old player has joined the market - GitHub with its GitHub Actions.
16. Introduction You can automate tasks of your development lifecycle such as build, test, analyze, bundle, release, and deploy. Having a good CI is crucial in your development flow. You can find plenty of material online on how to write good tests, but:
17. It’s useless to write tests if you are not running them
18. What is Git Hooks? Git Hooks are shell scripts that run automatically before or after Git executes an important command, such as "Commit" or "Push"
19. How to Use Git Hooks? Hooks are stored in the .git/hooks/ folder for each copied project, or in a newly created local repository. There, we can find a number of examples of Hooks, which are great starting points. To activate a Hook, it is only necessary to create a file and save it in the .git/hooks/ folder. However, the file name is predefined by Git. For example, I want my team members, every time they do commit they should follow a format: Ticket Number – Description minimum of 20 characters.
20. How to Use Git Hooks?
21. How does it work? 1. Developers check the code locally and commit changes to the repository. 2. Repository sends a request (web-hook) to CI system 3. CI server runs a job, which will generate a build and run tests to ensure your code works as expected. 4. Finally, deploy the APK file to production(Google Play Store)
22. Motivation For me, there are three reasons one as an individual, second as a developer who is working in a team and third is a business perspective.
23. As an Individual 1. I want to be a lazy developer. 2. I want to increase productivity by saving time from repetitive tasks.
24. As a Developer Helps to you keeps your focus on important tasks (or not) Your builds automatically deployed to an QA without you or anyone and also published your apps directly to the play store on a beta channel with one click.
25. As a Business You implement this to save you and your team time. Your team is more productive to implement more features in less time.
26. II. Tools, Providers Deploys and Pipelines
27. A picture always reinforces the concept
28. Single Pipeline - Grouped jobs
29. GitHub is a repository hosting platform based on Git, originally launched in 2008 by Tom Preston-Werner, Chris Wanstrath and PJ Hyatt. This is the largest repository host, with more than 38 million projects. https:/ /github.com/ GitHub
30. Bitbucket was also launched in 2008 by an Australian startup, originally supporting only Mercurial projects. In 2010, Bitbucket was acquired by Atlassian and since 2011 it has also started to support Git hosting, which is now its main focus. It integrates perfectly with other Atlassian services and its main market is large companies. https:/ /bitbucket.org Bitbucket
31. GitLab started as a project by Dmitriy Zaporozhets and Valery Sizov, providing an alternative to the repository management solutions available in 2011. In 2012, the GitLab.com website was launched, but the company was only incorporated in 2014. https:/ /about.gitlab.com/ GitLab
32. Pull request Code review Inline editing Issue tracking Markdown support Two-factor authentication Each platform is a large universe in its own right when it comes to resources and capabilities. But if we are looking only at the basic features, they show many similarities: Basic features Advanced permission management Static web pages hosted Feature-rich API Repository actions: Fork / Clone Snippets Third-party integrations
33. Bitrise - Buildings
34. Bitrise - Workflow
35. GitHub - Actions
36. GitHub - Actions
37. Conclusions What did we learn? III.
38. Your team should be 100% confident and always ready to deploy which is only possible if you have good code quality with unit tests and proper CI, CD, CD pipeline.
39. Not all flowers
40. The implementation of a decent CI pipeline and a complete CD system takes months and requires collaboration and quality assurance from the DevOps team, operation engineers, Scrum masters ...
41. Continuous delivery is the concept that all changes to the base code go through non-production environments first.
42. The team finds and addresses issues immediately, not later, when they have already released the code for use.
43. Continuous deployment is the concept that all changes made to the code are deployed almost immediately to production.
44. When releasing the base code for production is a business decision.
45. CI feeds CD.
46. Everyone must contribute. Perhaps the most difficult aspect of CI/CD is this human factor, rather than any of the technical challenges we have discussed.
47. Just as you cannot program a healthy relationship between two people, you cannot automate collaboration and communication.
48. Alternative Resources
50. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, and infographics & images by Freepik. Any doubt, criticism or suggestion just ping me: @jacksonfdam jacksonfdam@gmail.com THANKS