No matter the size of your organisation, if you are not using pull requests in Salesforce, you really should start from this single practice that has the highest impact over effort ratio.
Salesforce pull requests can help your organisation with:
- Change control management
- Quality gate
- Hands-on knowledge sharing
Change control management
Change control seems to be far from agile and CI/CD, a sort of bureaucracy that we don’t really need anymore. But if you can keep it lightweight, change control can be really beneficial to keep all the team on the same page about practices and, overall what is going to be released at the next deployment. No matter the size of your organisation but this could be a real challenge, and sometimes save you the day from really bad deployments.
Pull requests are a very lightweight documented practice to define what is going to be released and why. Many git providers have already some templates in place ( Github, BitBucket ): you could use templates to add a checklist for tasks that are out of the coding scope but still part of the release process, for instance, write documentation or engage the marketing team.
Quality gate
Quality is an extensive term in this context, from coding conventions to testing practices or even design patterns. Again it may sound a heavy word that does not play well with Agile common sense, but any business needs to monitor the quality of their services or products.
Pull-requests enable peer-code reviews and overall to centralise the control of quality in the place where your code lives, the repository. Tools like Clayton for example, without the need of a fully bloated CI/CD, can listen to your code changes thanks to pull requests and enable your team defining the quality bar they aim to stick on.
Hands-on knowledge sharing
Sure there are many ways we can share knowledge, but if this pandemic teaches us something, it is really a valuable asset to have collaboration and knowledge sharing using cloud based tools.
Writing pull-requests enables the very healthy habit of reviewing your own code, as much as reviewing teammates code, to learn new things or trigger healthy discussions.
Where is the catch?
It is not all so easy and breezy. Learning how to write good pull requests and review them takes time and has a lot of pitfalls. It can be very time consuming and could trigger conflicts in unprepared teams. Following some tips and tricks, you can lead your team embracing such a powerful practice for good.
I still remember one of the first pull-requests I submitted when I was a developer.I was new to the team and I got nitpicked to death. They were all good points, the main problem was that I wasn’t informed at all of all these coding rules. Overall I had to submit my pull-request several times because each time the reviewer of the moment was warning me only of the first handful of problems.
This is why at Clayton we truly believe that AI and automation can relieve developers from most of these common pains.
The machine can do all the nitpicking and senior engineers can save time: nobody will take it personally, it is a machine! All the coding rules are documented in the system and also can be easily used for new engineers onboarding. In case there is any controversy about best practice, you can easily face it and set up your new policy, so that from now on will be the machine to take care of it and promote the change across all developments automatically.
