Salesforce Developer MVP Anup Jadhav shares his thoughts on Salesforce development, Continuous Delivery, version control, and more. He also discusses the challenges of implementing Continuous Integration and Continuous Delivery in Salesforce and his excitement for Salesforce DX and Einstein.
With this article, learn about the experience of a Salesforce Developer MVP, Anup Jadhav, and his thoughts on Salesforce development, version control, Continuous Delivery, and the recent Dreamforce announcements.
Here are our 5 Key Takeaways:
1. Force.com is a powerful platform that allows for agile and speedy application development with minimal coding.
2. Version control is crucial for tracking changes and introducing a code review process into your workflow.
3. Continuous Integration and Continuous Delivery are challenging for Salesforce development teams due to limitations in the Metadata API.
4. Salesforce DX offers more control and options for automating the deploy process, making developers more productive.
5. The new CLI and Scratch Orgs in Salesforce DX will be useful for dev testing and data testing.
Anup was kind enough to share his thoughts on Salesforce development, Continuous Delivery, version control, Einstein and a range of other topics related to Force.com. Anup Jadhav is a Salesforce Developer MVP based in the United Kingdom. He is an experienced software developer, technical architect and engineering manager with over 12 years of experience developing web and Salesforce applications for top tier companies. Anup has worked mostly in the Financial Services and Media sector with over 7 years of commercial experience working with the Salesforce platform.
He is also the founder and co-organiser of the London Developer User Group. Read more from Anup at his blog: www.anup.io and follow him on Twitter @ Anup .
How did you get started on the Force.com platform? I was a Java and C# developer originally. I’ve been doing software development for twelve to thirteen years. I did Java and C# for five to six years and then I was working for a company locally in Redding who were using Salesforce. This was around the time that Apex and Visualforce was launched.
Because Apex is very similar to Java I picked it up very quickly and I taught myself Salesforce. When I realized how powerful this platform was and the kind of stuff that you can do with it, I became a full-time Salesforce developer. From there I joined a couple of consulting firms doing salesforce development, implementation, business analysis and technical architecture.
What makes Force.com such a powerful platform? What I really liked about the platform was the agility and speed with which you can build applications. Coming from a Java background I was used to doling a lot of initial setup. Even though you have frameworks and libraries which helps you build apps, you still have to worry about security, scalability and software and hardware maintenance.
I use version control for almost all my projects. I say “almost” because sometimes when you work as a consultant you can’t enforce that, but whenever I can I try to use version control. I like to use Git because it has a very cool command line interface. Whereas with Salesforce app platform, almost everything is set-up for you and it helps you focus on building awesome apps. Most of what you need to do can be done with point and click with zero to minimal coding. And for things that you can’t do with point and click you can use Lightning framework, Apex, Visualforce very quickly to build an application within days or weeks.
Was there any challenge getting started with Salesforce? It wasn’t that challenging for me to get started because of my Java background. I worked with JSP before which prepared me for the whole Apex and Visualforce model. The most challenging thing for me surprisingly was the security model. I think it took me months to wrap my head around the whole security model and finally get it.
Surprisingly, learning some of the Admin aspects of Salesforce took me more time than the development aspects.
Do you spend more of your time in something like the Force.com IDE or developing through the UI? It depends on the project. If the project involves a lot of complex business requirements that cannot be implemented using the point-and-click tools, then I spend a lot of time in my IDE. I used to use the Force.com IDE Eclipse plugin. But ever since MavensMate for Sublime Text came out I have been a MavensMate user.
I spend maybe 60% of my time in the IDE and 40% in the UI.
What are some of your favorite tools? First of all I use version control for almost all my projects. I say “almost” because sometimes when you work as a consultant you can’t enforce that, but whenever I can I try to use version control. I like to use Git because it has a very cool command line interface.
Version control is important is to track your changes. You won’t realize how useful it is until you want track who’s changed what. And it happens quite often that you want to do this. I love the terminal. Because I like the terminal I use the Force.com migration toolkit to deploy. I try to use that instead of change sets and use source control to track all my changes.
I use Jenkins sometimes for CI. It depends on the project. If the project is large and complex we set up a Continuous Integration server and link a branch to the Salesforce Org and to Jenkins so that every time you check in or deploy it will automatically run tests for you and then deploy all of those new classes and artifacts.
Why is source control important? The reason version control is important is to track the changes to the codebase over time. You won’t realize how useful it is until you want track who’s changed what. And it happens quite often that you want to do this. One of the things that happens quite often in development is you want to know how a particular class evolved if a bug appears. So you want to know who changed what. This is not necessarily to assign blame but to be able to understand the evolution of the business process logic that’s been implemented.
With Git, you can introduce a code review process into your workflow which has a tremendous impact on the quality of code that you produce. Obviously the other thing is that it acts as back up so for whatever reason (especially in a scenario where you’re working in a common sandbox, where multiple developers work in the same sandbox) it is possible to have one developer step on another developer’s toes by overwriting someone’s changes. In that case, it’s useful to have source control to keep track of those changes so that you can safely rollback to a previous version.
How long have you been using Git? I think maybe 4+ years now. Before that I was using SVN. Does anything make Git ideal for Salesforce developer? Git works very well with the Salesforce workflow and its distributed model aligns well with salesforce org strategy. Instead of directly committing to the main repository, you can push a patch and someone in your team can review that patch. People can easily see if changes match coding standards or if there is any danger of introducing a bug. With Git, you can introduce a code review process into your workflow which has a tremendous impact on the quality of code that you produce. This, however, requires discipline and a team culture that enforces best practices around using version control.
What are the biggest barriers for Salesforce development teams today in moving towards Continuous Integration and Continuous Delivery? When I say Continuous Integration (CI) I don’t mean it in the traditional sense. If you talk about Continuous Delivery and CI in the Java and C# sense, what you mean is that your workflow enables you to push something to your Git repository or other version control system that you are using. This automatically starts a process of automatically running all integration tests and unit tests and Selenium UI tests, and then maybe deploying to other environments like qa, uat and even prod. That’s the traditional CI model.
The main benefit of CI that it identifies any issues with code quality early on. If you identify something that breaks the code early on. This makes you more careful with what you’re committing and more careful with your tests as well. We can’t do traditional CI with salesforce at the moment because we cannot automate deployment for all artifacts. One of the challenges that we have is that the Metadata API (which is used by the Force.com Migration toolkit) doesn’t support all of the artifacts. So you can’t deploy things like Email services, quote templates, site.com etc. You have to deploy them through the UI using either change sets or through manual steps. This prevents us from automating the deployment. So given those challenges you can set up a limited CI where you connect a CI server to a Salesforce Org. You set up a rule that says if I commit to this dev branch or CI branch then pull all code from that branch deploy it to the Salesforce Org and run all tests and emails the success/fail result to the team.
What is the main benefit of setting up even this limited CI? The main benefit is that it identifies any issues with code quality early on. If you identify something that breaks the code early on. This makes you more careful with what you’re committing and more careful with your tests as well. You will write better tests that are more effective.
It does improve the quality of the code you produce so it’s still worth it to set up. It might take you a day or two to set it up but once it’s there you don’t have to do anything.
What was the most interesting announcement at Dreamforce from your perspective? So there were two announcements that were interesting to me. Einstein obviously but as a developer I was most excited about Salesforce DX. one of the things I missed when I started Force.com development is the seamless “develop, build and deploy” workflow that I was using during my Java/C# days. The workflow started with the version control and you could automate almost everything back then. Continuous Integration and Continuous Delivery wasn’t too hard.
Given the challenges that I mentioned earlier - you can’t write scripts for deploying everything for example - Salesforce DX gives us more control as a developer and also gives us more options to automate the deploy process. So with DX rather than starting with an Org and then adding stuff to the repository, we start with source control and then deploy to the Org so that your version control repo becomes the source of truth. So it kind of inverts the process which is what we want if you want to adopt a workflow which works easily with version control and Continuous Integration.
I think it will make developers a lot more productive. The new CLI along with Scratch Orgs will be very useful to do dev testing and data testing quite quickly.
What are your thoughts on DX? The new and improved CLI opens up the possibility of Continuous Delivery for Salesforce. It also will let us automate more things than we can right now with the tools available. Automation and Continuous Delivery means good quality code, it means speed in development. We can start building apps even faster on Force.com.
The other announcement you mentioned was Einstein. What are your thoughts on Einstein? We are lucky to live in a time when we are going through an AI (Artificial Intelligence) revolution. Even if it’s not true AI or artificial consciousness, it’s fascinating to see companies like Google, Facebook, and Microsoft investing their resources to create smarter machine learning algorithms which will have an impact on all aspects of our life.
It was interesting that Salesforce would focus their attention on AI. It kind of makes sense in the grand scheme of things. With Salesforce Einstein they are bringing AI to the enterprise. From the demos that I’ve seen it shows great potential. At the end of the day I can’t really comment on it without trying it out and playing with Einstein. But I can see huge possibilities with the prediction capabilities. For example, predicting whether a lead will close or not, or predicting the opportunity pipeline for you. It might take a lot of manual effort away from enterprise users. It will be interesting to see how Einstein is weaved through existing salesforce products.
From a developer point of view I’m excited to think about what kind of applications we can build on the platform now using Einstein. One of the things they were demoing is the Vision API (I think it’s called). It could run its algorithm on faces and then if you show it that face in different locations it will recognize that person. That opens up opportunities to build innovative applications on the platform.
When will we see a lot of Einstein apps going to the market? Since I don’t work at Salesforce or privy to the Einstein roadmap it’s hard to say, but if I were to hazard a guess, I would say it’s still a work in progress. Even though they showed a lot of demos at Dreamforce, it felt like a controlled demo. We are probably looking at six months to eight months to get our hands on something more concrete. But then again, I’m shooting in the dark here. Caveat Emptor and Forward Looking Statements and all that jazz.
What will we be talking about at the next Dreamforce 1 year from now? Well, Salesforce has tackled almost everything. They tackled IoT (Internet of Things), they are tackling AI, so definitely we’ll see more of Einstein next year and it works across their product suite. If I have to take a guess one of the technologies that we’ll see is the technology behind Bitcoin: the block chain. The block chain or distributed ledger is disrupting the financial services sector. So I predict we will see something around block chains and the Salesforce platform.
Any thoughts about the upcoming Winter ‘17 release? Winter ‘17 is a big step forward for Lightning Experience. They’ve released a lot of LEX features for Sales Cloud, Service Cloud, Community Cloud and other clouds. This release probably takes us to 65-70% closer to transforming from Classic to Lightning. From dev point of view, I’m excited and looking forward to using base lightning components, along with Custom actions which will provide an elegant solution for custom javascript button actions from Classic. Locker service is a welcome addition from security perspective. This release will definitely encourage devs, admins and users to move from classic to LEX.
What are you most excited about for them to improve with Lightning? I’m most excited about how Lightning components can play into the standard interface. I think there’s a lot of potential if they do this right. So you can customize every aspect of your Lightning experience. If they achieve that goal then all this pain in the transition is worth it because it will open up so many possibilities in how you can configure Salesforce or build components or applications on the platform.
Is there anything I haven’t asked you that you’d like our readers to think about/know? Lightning and even Salesforce itself are in their early days especially from a development point of view. What’s not mature enough is development practices, especially for small to medium sized teams. The larger teams often have some kind of process. But with the launch of Salesforce DX, I would like to see some common best practices be adopted by the community. I think as a community we need to come together and say these are the things that work well on small, medium and even large sized projects, and then create a development framework that makes us all productive and better developers.
Any advice for our readers that are interested in getting into Salesforce development? Keep an open mind. Especially if you come from a Ruby, Java or C# background, the development paradigm might seem a bit unfamiliar and in some instances restrictive , but it’s worth it in the end. Especially if you’re building large enterprise applications. Salesforce plus Heroku will take care of a lot of pain for you. All you have to do is understand the best practices and paradigm of working in the Salesforce ecosystem. Things like governor limits may seem at first restrictive but they actually help you become a better developer and make your apps more efficient.
