Last week I completed the Trailhead beginner and intermediate developer courses available at http://developer.salesforce.com. During the course I was able to complete all development using their online IDE with relative ease and success – it was very impressive. Its only shortfall is that it does not support source control and one of the solutions they recommend is to use Eclipse with Force.com IDE. The results blogged at Salesforce and Eclipse…. arghhh!!
Failure is not an option
In the context of usability (and what I’m accustomed to) it failed miserably working with a VERY large org and failure was not an option. A means to retrieve the Salesforce org contents, place it in source control, and migrate it to my Salesforce Development Environment (DE) had to be found – The Welkin Suite came to the rescue. It is a great time to be a Salesforce developer because this developer suite, powered by Visual Studio, is shortly going to be released and as of this writing is in beta. I’ll describe my successful adventures using this tool to retrieve a very large Salesforce org, in processing updates, deploying them back to Salesforce, and migrating those changes to my Salesforce DE.
I have some QUICK START tips at the end of this blog to fill in some blanks for those developers who want to ramp up in a few minutes to this product.
If you’re a Visual Studio user like myself you will be excited about the following screenshot – it will feel right at home to you.
More important than anything else is the support team and staff – they are very, very impressive. Bear in mind that this product is in beta and as such issues are to be expected, none of them were blocking and I promptly reported the few I did encounter to the team. Most of the issues were already on their radar and/or fixed (for the upcoming release). For a minor issue that wasn’t, I was sure to provide detailed information and I got an immediate [next day] response; I might add it was a very appreciative reply from a support member that noted my issue was under investigation and they thanked me for my time. Every issue reported was addressed with detailed reasons [for those on their radar] as to their cause and I was made to feel like I was a VIP customer of their product - that my input was the most important event for their entire team. I have not seen this level of support on a product (particularly one I am not paying for). I’m sold, as soon as it is released I am going to jump on their Enterprise edition. For a $25.00 monthly subscription I will get updates/full support and I’ve already seen what they do for free customers, so it will be definitely worth the extra $10 (over their professional version) to get the level of support they provide. FYI: they do provide a free unsupported application as well.
Welkin Suite Team
Since I already have a solution with two projects (corporate and developer environment orgs) created as of this writing I won’t show a screenshot of the actual creation process, but it is similar, simple, and intuitive. You will provide login information and a dialog will appear as it retrieves metadata from the applicable org. I will note that the first dialog does not present a filter option as shown in the screenshot below so after it retrieves the initial catalog of available metadata I deselected all of the default selections (hundreds that didn’t apply), selected only one object, and then let it generate the Visual Studio project files so that I could then right click on the project and select “Project metadata components” as shown in the screenshot below. Since this dialog is executing code asynchronously you can now input your filter selection, I input “LMSF” and approximately 6 minutes later my list of objects was available and within my project!! Note that my corporate org has coding standards that require us to have a four character prefix for “all” objects so that there are no conflicts – this standard happened to make this great feature a plug’n play for getting all of my objects quickly located and selected!!!
So let’s pause and talk about that 6 minutes, it may have raised an eyebrow but all things being relative the performance of this Welkin Suite process is impressive. If you launch Fiddler (shown in the bottom right of image above) you will find that 95% of this time is spent querying the information from Salesforce – the bottleneck is not in the Welkin Suite but Salesforce itself, particularly since this is an enormous org. Case in point when I ran the same process in Eclipse (reference Salesforce and Eclipse…. arghhh!! blog) the process took well over 15 minutes before I could even access the IDE. Once accessible I didn’t realize it wasn’t done yet importing (being new to the IDE I thought it failed to get all objects so I tried again) so it was really upset and started dragging into the ground – nothing I couldn’t eventually get out of with the task manager after much frustration. So 6 minutes was MAGICAL and high performance; when Salesforce was done with its part – the Welkin Suite screamed performance.
So after HOURS of frustration with Eclipse Force.com IDE (blogged about in link above) I was ecstatic that within 10 minutes I had retrieved my meta data from an extremely large org and was up and running!!! Welkin Suite – you had me at 10 minutes!
But it wasn’t done impressing me yet, I created another project for my Salesforce Development Environment (DE) and pulled everything down in a fraction of the time – my environment only contained the objects created during the Trailhead beginner and intermediate courses. It smoked this small org and within a few minutes I was able to see how the unit test features worked – I was shocked to see that I was able to actually step through my APEX unit test exactly as I’m accustomed to with C#, I even had local variables that allowed me to see what was going on – The Welkin Suite folks now became my best friends! Up to this point everything had to be done with logging statements and being a new APEX developer completing solutions to the trailhead tests it was like putting on a blindfold and walking into a maze. The Welkin Suite is amazing and now I am chomping at the bit to start writing my APEX applications!
Prior to this it was a rather daunting and depressing venture, why? I was quickly reminded as I attempted to migrate my application from the enormous corporate org to my Salesforce DE that you have to have 75% code coverage to deploy (try that blind-folded). This is yet another place the Welkin Suite exceled! I simply right clicked on my corporate org project, selected “Deploy to organization” (see left pane of image above), filled out the login information and walla! It failed with detailed explanations why – I had currency fields that were not available in my DE org. Turns out that my corporate org has Salesforce Winter 17 which is newer than my DE org. I had to go to the layouts noted in the failed deployment report and remove the currency fields from them. I then complied with a “Deploy to organization” and walla! It failed again – this time because I only had 45% code coverage
now this was a blocking issue – but it had nothing to do with the Welkin Suite.
Deploy to Organization
I had to get 75% code coverage or remove all of the culprit classes from my DE. So if you are trying to deploy to your DE after taking the Salesforce trailhead courses be forewarned – you will have to reset (remove) all classes, triggers, unit test, etc. before you can deploy to your DE or write the unit test (no ROI in that). In hindsight I wished I had removed the triggers first, then removed all “xxxxController” references from the APEX pages, and finally removed all classes. Instead I got a lot of error messages and broken links because I was unable to remove components because they were being used – it was a long drawn out process.
After I completed the reset of the DE (which by the way there is no automated way to do) I did a “Deploy to organization” and walla! Success, within a few minutes I deployed from my corporate org to my DE and I didn’t have to touch a command prompt. This is significant!! I was originally dismayed to learn that to use the Salesforce Migration Tool that I was going to have to digress to a command prompt and type in many different command line statements to perform the migration. Not so with Welkin Suite – simply login, point, and click; true to Visual Studio tradition, spoiling us with features on a silver platter.
“I’d rather fight than switch”
So if you are not totally impressed by Welkin Suite, don’t take my word for it. Try Eclipse and Force.com IDE and find out for yourself, but do not neglect to then try the Welkin Suite because the productivity it offers will sell you within a few minutes. If you are a corporate developer on a large org that will be doing APEX coding – I wouldn’t waste my time with Eclipse, you will be VERY, VERY thankful to the Welkin Suite team and their hard work and commitment to this project.
As I eluded to, most C# developers are spoiled as we are accustomed to everything being handed to us on a silver platter – we generally want to jump right in and within a few minutes be able to get the task at hand done. This section is dedicated to those because where this application is highly intuitive and easy to use – there were some areas that forced me to do some research (and be cautious of as I have admin access to my org) because I didn’t want to break something.
So creating and pulling information from Salesforce – piece of cake no brainer. But how do you update your changes to your Salesforce org after you are done? Very simple, simply “Build” the project or “Deploy” it. I didn’t know the difference between the two so I posed the question to support and was not surprised to get an immediate response the next day – below is an excerpt from that email that demonstrates the level of support that I have been bragging on:
With my experience with Visual Studio and these questions answered I was focusing on the task at hand. Did I say this product was amazing? Well their support/staff is even better…
From: Kate Dulko [mailto:firstname.lastname@example.org]
Sent: Thursday, September 15, 2016 6:45 AM
To: Bill Kratochvil <email@example.com>
Cc: Info TheWelkinsuite <firstname.lastname@example.org>
Subject: Re: Verify bug submissions are being received
We are glad to get your response.
I would be glad to provide the information you requested. Here this is:
• "Deploy Objects": the build functionality, that you have mentioned helps you to update your Organization on Salesforce with the new changes made inside The Welkin Suite, but the Build option applies for the next Salesforce metadata types only: Apex Classes, Apex Components, Apex Pages, Apex Triggers, Aura Definition Bundles, and Static Resources. If you work with other types of metadata and need to move the changes in them to an org, please use the functionality of Deploying Objects.
• "Enable project structure sync": The Welkin Suite gives you an ability to create your own project structure. This means that you can create separate folders in the Solution Explorer, move your project files between default and your custom folders, or move folders inside the project structure. Enabling project structure synchronization allows you to store this structure on Salesforce or share it with your colleges. More detailed information about this feature you can find in the Release Notes blog post.
We will be happy to help you and answer your questions related to any other TWS process or feature. In addition, next week we will publish the Refreshed TWS Documentation which will allow you to find any necessary information easily.
The Welkin Suite
skype id: d_katerina_