Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie CI/CD - A strategy for success (North Africa Dreamin' Prez)
Ähnlich wie CI/CD - A strategy for success (North Africa Dreamin' Prez) (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
CI/CD - A strategy for success (North Africa Dreamin' Prez)
- 1. ” “ Casablanca, 19.10.2019 CI/CD – A Strategy for success 10x Salesforce Certified Application Architect / Tech Lead @ Accenture Belgium Yassine El Qandili /in/yassineelqandili/ y.elqandili1@gmail.com
- 2. Why CI/CD ? What is Continuous integration & Continuous Delivery/Deployment ? How to do CI/CD ? • Sandbox Strategy • Delivery pipelines • Branching Strategy • Salesforce DX Agenda 2 3 1
- 3. Why CI/CD ?
- 4. Auto CI : Continuous Integration Small Changes Frequent code check in from VCS Automatic package, build & test CD : Continuous Delivery: Manual trigger deployment to production Continuous Deployment : Automatic Deploy to production environment Build Unit Tests Deploy to staging Acceptance tests What is CI/CD ? Manual
- 5. Align Design •Implement 1st Step 2nd Step 3rd Step Technically implement & document the solution Train your team on the new WoW Align business objective with the technical implementation Create a repository of existing tools Design deployment flows & release cycles to respond to business challenges Make a choice on the tool stack How ?
- 6. CI Server Dev Sandbox Dev Sandbox Dev Sandbox CI Sandbox QA Sandbox Production HotFix How ? – Sandbox Strategy This Photo by Unknown Author is licensed under CC BY-SA Build Unit Test Integration TestReview & Approve Auto Test Deploy Continuous DeliveryContinuous Integration Scratch Org Scratch Org Scratch Org Scratch Org Scratch Org
- 7. Development UAT Production How ? – Delivery Pipelines Development SIT UAT Production Development Merge SIT UAT Performance Testing Staging Production
- 8. How ? – Branching Strategy Master QA Develop Feature 01 Feature 02
- 9. Salesforce DX Salesforce CLI Source Format vs Metadata Source ? Tool stack How ? – Implement 1 2 3 4
- 10. Salesforce DX
- 11. Powerful Command Line Interface Perform commands against your Salesforce Org Synch code from your org Create and manage orgs Import & Export Data Create and execute tests Create and Install Packages Salesforce CLI
- 12. Metadata Format vs Source Format
- 13. • VS Code: Free & Open Source IDE • Salesforce Extensions • CLI • Apex & Apex Debuggers • LWC, Aura Components & Visual Force • GitLens Tool Stack – VS Code, Salesforce Extensions & GitLens
- 14. Endless Possibilities Tool Stack – CI Tools
- 15. Happy Development team Happy functional team Happy Product owner Happy sponsors & stakeholders Happy users Happy Customers Happyness
- 16. THANK YOU for attending this session And thanks to our sponsors
- 17. ” “ Casablanca, 19.10.2019 Q & A 10x Salesforce Certified Application Architect / Tech Lead @ Accenture Belgium Yassine El Qandili /in/yassineelqandili/ y.elqandili1@gmail.com
Hinweis der Redaktion
- This session will no be about how to technically setup your pipelines and will not be focus on the tools as such (except for Salesforce DX because it’s the backbone) In the How part, we’ll see to practically tackle this subject at a customer & in which steps ?
- Not only in the World of Salesforce, We all know the perks of deployments and we know how much it’s underrated & the risks of last minutes errors that come along. Now I assume you’ve all used change sets before & for sure you know that when working in separate teams on the same org, using changesets becomes a Russian roulette. Continuous integration and deployment comes into the picture to make it possible to avoid those challenges and automate most of the steps in this process in order to focus more on things that matter, bringing more business value rather than wasting time debugging errors.
- Continuous integration is the process of continuously & automatically merging the changes made by developers in a single source of truth (VCS) testing them and deploying them in a common environment where they co-exist together, to be able to detect compatibility errors early on the process so that you’re able to fix them as quickly as possible as well. Continuous delivery picks up where CI has left, to deploy to higher environment (QA or Prod), but still requiring a manual trigger. have a manual intervention when going to higher environments, such as QA (SIT/UAT, Staging) Continuous Deployment, is when everything is automatic, which is definitely more mature, so you shouldn’t do that if you’re just starting out.
- A lot of your time will go into alignment Align : (Common understanding of the objectives & responsibilities) Understand what business want to achieve with Agility : Release vs Feature A mix of both might mean smaller sprints. Teams : parallel projects, running support (Change sets – cannot be used anymore) Corporate standards & tools Responsibilities: who do release management, coordination (code merging, code reviews, triggering deployments) Design : What’s the definition of your QA, what’s the development model (DX, Scratch orgs, Org VS Package) & release cycle, Tool stack. QA environments: Environments & who will test in each env Analyze different approaches : Org Model vs Package model, Source format vs Metadata source. Release Cycles : 2 weeks, 3 week. => short Implement: Working tested solution, trained developers. Start executing Implement your release pipelines & document what they do Document the developer flow : how the developer day will look like Train the team & allow for mistakes in the beginning
- Downsides of sandboxes : they’re limited, they get outdated, they might be used by multiple developers. Scratch codes: is more of, the developers own local development environment that he will use only for one feature and the get rid of it after the code is merged into the repository. They’re Fresh, and quick You CI automated tests will again run in exactly the same type of Org created from scratch which makes more consistent.
- Once you have your sandbox strategy, As part of your QA you’ll have to define the pattern to which each feature will go through. That will differ from one project to another and from one customer, sometimes you want to do performance testing because you have some heavy processes, sometime not.
- Objectives of features branches : Track changes and relate them back to User stories Know who did what & at which point in time Clear history
- Salesforce DX is a Salesforce product from the App cloud, that help you do your developments on the Platform.
- Smaller meta data files More readable Less merging effort Clearer structure