SalesforceSummaries: a series delivering key insights from Salesforce YouTube videos, to save you time as you keep up to date with the latest technological changes within the Salesforce ecosystem.
Introduction:
The purpose of this overview is to help give admins insight to why they have challenges related to deployments and provide the tools and processes to improve.
Details:
https://youtu.be/SGiBNMahr6g?list=PLZwrPTK28KcFzoRzzZhUkHXlaRg2W689m
Video: ‘The Ideal Salesforce Development Lifecycle’
Presenter: Joshua Hoskins
Date: November 25th 2013
Time: 61 minutes
Key terms: Change control process, release cycle, Salesforce deployment
Key points: The more you deploy, the better you will get at it. Depending on your org, there are different preferred methodologies for deploying to your Production instance. With the proper measurements and planning, formal change control process and communication (i.e. governance) combined with the right tools (change sets / Force.com Migration tool / Salesforce DX), your Salesforce deployments should go seamlessly.
- @3.00 — What type of scenario applies to you, regarding deployments? The people who are re-active tend to take too long working on ‘quick fixes’ which actually take a lot longer than thought.
- @4.15 — In order to be confident about deployments, you need to deploy often.
- @7.00 — All of the roles below play a significant role in deployments. Whoever is doing the configuration or development should not have a QA role. You always need to have checks and balances in place.
- @9.40– Unfortunately, so much of software deployment is as follows:
- @10.10 — You need to benchmark before you start developing and you need to be able to measure after the end of deployment whether you have been successful or not, with your original objectives. The ideal recipe for deployment success is: define, design, deploy and measure.
- @10.30 — The kind of conversations which your team should be having are:
- @11.15— Best practice is to define before you design:
- @12.50 — Secondly, designing before developing is critical and can save so much time. The type of questions you should be asking are related to the below:
- @13.00 — When you ask these kind of questions, you’ll be thinking about the ‘how’ — how should or how could I do options A, B, C. Designing before developing can rapidly cut costs when prototyping.
10. @15.00 — Develop a prototype user story and then demo this to users before continuing. This too, can save a lot of time. Oftentimes, users aren’t sure what they actually really want and so a demo that has been created, aided by designing, can massively help.
11. @15.40 — Reviewing before deployment is also best practice.
- @17.00 — The builders cannot be the testers, so keep clear boundaries and keep integrity even if you have a smaller team.
- @19.30 — Confidence with deployments = Team + Checklist.
- @20.00 — The role a person has in a team defines what ‘hat’ they are wearing. For example, the release manager is the conductor, deployer, responsible for identifying blockers and traceability (you know what you’re deploying and you know what you deployed last month).
- @24.00 — A typical checklist will be as follows:
- @29.00 — If you’re able to split big tasks into smaller tasks and share the workload with your team, then deployments can turn around quicker.
- @31.00 — When you design something, you want to think about how you can measure whether it is being used or not. You would also want to measure ‘value stream mapping’; which is measuring the entire process from start to finish. These are compelling metrics for an executive person. Value stream mapping helps one to make smarter decisions and smarter delegation.
- @40.00 — The more you deploy, the lower the risk in the long run. Some large companies deploy multiple times per day (Facebook, Etsy) etc.