As you may have observed, I was on hiatus for the last few months and the reason for that was CTA exam preparation.
The purpose of this blog post is to share my experience and motivate you to embark on this journey.
Lets bust some of the myths around CTA
- Getting designer certification does not mean you have good platform knowledge. There are many aspects that are not covered in designer exams like Tableau CRM, Heroku, Mulesoft, CPQ, etc
- Certification is not easy if you are a developer, admin, or consultant. Everyone has something to learn. If you are a good developer then you will need to work on your communication and articulation. If you are a good admin then you would need to learn customization capability etc
- This exam is easy for a few candidates who are CTO or have 15+ years of experience. That’s not true. Definitely some presale role, Architect & leadership experience will help in exam. EVERYONE that I have met has put hundreds of hours after office & over the weekends. Success may look easy from the outside but behind the scene, it’s a huge effort.
In my opinion, You need to have the right balance of Platform knowledge, Story Articulation capability, Overall strategy, and Time Management, which was my CTA Mantra.
Its been around 3 years that Salesforce has released new tooling set for developers – Salesforce DX. I’ve been working on Salesforce since days of S-Control around 2008 and have seen extreme changes on platform for better.
To be honest, it’s tough to keep yourself up to date on latest changes that Salesforce has been doing , however there are resources like Medium, Trailhead and many other blogs to help you get up to speed.
I’ve seen days and written code on Force.com IDE, Developer Console, many web based IDE and definitely my heart and love at the moment is with VSCode more importantly Scratch Org & unlocked packages.
Purpose of this blog post is to bust some of myths around using Scratch Org in Salesforce DX however before I start, lets agree on below aspects of project development & management
- Most of projects in Salesforce follows Agile and one of most important aspect of Agile is Devops. Your team should spend enough time & energy in planning Devops strategy like branch structure, tools, processes etc. In my experience , Devops is more about process rather than tool.
- On basis of above point, Source of truth for code & configuration should be your Source Code Management , which in most of cases is Git.
What if your project is not following above 2 principles ? Well, you might already able to relate some of problems like why code is overwritten , no track of which class or fields created by who and why ? Your team spending most of time fixing deployment issue instead of working on actual implementation.
Lets not spend more time and directly jump on some of myths about using scratch org
Myth 1 – Scratch Org is only for packaging & ISV partners
Scratch Org can be used for quick POC or actual implementations. I’ve been using scratch org for each user story which normally takes 1-3 weeks of implementation. Every time, scratch org created, I get liberty to choose which Git branch would be source of truth. Can you refresh dev pro sandbox from Full copy or use 10 days old code that was in production ? There are many other considerations while creating sandbox, you don’t have much control on which metadata would be carried over as starting point.