The Welkin Suite Blog

We see the Salesforce platform constantly evolving, and along with that, we see the development processes transforming as well. But do we only see this evolution around those what I would call buzzwords of Salesforce, like moving from Visualforce to Lightning, Salesforce DX, or even about the progression away from having to use code at all? I would say no, and I think a great example of this is how the development and development flows have matured around Apex. Just 5 years ago using GIT with Apex projects was a very scare world in Salesforce, and now it is not scary at all as the tools, developers, and workflows have grown.

So let’s talk today a bit about the different options you and your team have in The Welkin Suite to store your sources and metadata in Git. I am not going to mention anything about flows and best practices, as each project and team is unique in its way of using Git, so we’ll just highlight what you can do in the IDE to make your Git journey easier and more comfortable.

Ok, we have to admit that at the time of our writing this, we haven't yet released The Welkin Suite Bloom R19, but we'd still like to share with you some of the new great additions that it will introduce so that you will be up to speed by the release. So with that comment out of the way, one of the most very common questions we have had over the past years has been "How to work with my sources that are in Git in The Welkin Suite?" - today we're going to be answering this question.

If you are adding new fields to sObjects often, you know how time-consuming this can be, even if you are just accomplishing this task for a couple fields, because you have to bother with configuring the layouts, and setting up the FLS. More than 100 years ago Henry Ford applied the moving assembly line concept to his production method, however we don't have such an option for sObjects modifications, at least if you don't want to be dealing with the fun of XML files, however, even going down this road, you won't have the full speed of being able to modify and configure the objects and related settings.

Even though Salesforce has always been an innovative platform, just a couple years ago our troubleshooting options seemed as they were much more closer to the stone age, especially when we were comparing them to the other development platforms like Java or .NET. We were using things like "System.debug()" to print out important information to the log files, and then we were analyzing hundreds and thousands of lines of logs (I can feel the migraines and the sandpaper eyes just thinking about this now). However since that time, we already have had a great amount of tools for debugging become available to us - you can see a short overview of some of them below, and even further below, we'll highlight a couple of common scenarios that we are normally faced with, and how to handle them with these tools

There are 2 ways in Apex to get the describe information on sObject and the fields in Salesforce. The first one is Token — a lightweight, serializable reference to an sObject or a field that is validated at compile time. The second is a describeSObjects method — a method in the Schema class that performs describes on one or more sObject types. Both these structures return you Describe result — an object of Schema.DescribeSObjectResult type that contains all the describe properties for the sObject or field. Describe result objects are validated at runtime, and cannot be serializable. DescribeSObjectResult object is returned when performing the describe, using the sObject token or the describeSObjects method.

With a recently released The Welkin Suite Nova R1 version, we have added the support for the External Tools usage right from the IDE. In this small post, we will show you a couple of examples how you can unleash the power of such a "small" feature in your daily tasks. First of all, if you are not familiar with this feature - check out our documentation, so you will know how it works.

In our Salesforce development experience, we are using the External Tools mostly for such kinds of applications:

• Executing some Ant (Salesforce Migration Tool) tasks
• Automating the work with Git without any interactions with UI
• Minifying or beautifying CSS or Javascript files from our static resources.

ll you know that Salesforce development environment is not the best in the world. You know that one tool can work much better with some feature that others when another one can do some other stuff in the best way. o, which tool to choose for an everyday work is a good question. Some oldschool folks choose Force.com IDE when others can do the best with Mavensmate, Welkin Suite or even Developer Console. For a few years Mavensmate was my favorite IDE. But a few months ago I found Welkin Suite as pretty cool tool. So, I decided to merge Mavensmate and Welkin workspaces in order to work within just one workspace.

The Welkin Suite Nova is on the way - so it’s now time we show you how to move from the Beta version to the production version in just a few steps.

Ever since Salesforce announced its Lightning Component Framework, not only has it immediately become the core of a series of discussions--it has also raised the bar for technological advancement of Salesforce applications and IDEs. As a result, in a number of ways this has established the direction for Salesforce development by introducing a set of integral features, which have to be taken into account and added to the functionality.

How often were you getting lost in the enormous amount of previous versions of files you were trying to maintain? Naming files like ‘code_ver1’, ‘code_ver2’, …, ‘code_ver45’ is workable solution, but not for large software projects. You need to have an ability to easily get back to a previous working version without digging through what changes were made and why. Add to this collaboration with other developers on a project, and you normally end up with an absolute mess.
The best solution, in this case, is a Version control system. This allows you to keep all the previous versions of your files as well as roll back to any of them, compare changes over time, define who and when made changes, and much more.
For all these issues The Welkin Suite has a built-in Git support, so you can work with a Git repository right from The Welkin Suite without switching to any other applications. You have an ability to commit your changes, work with different branches or create your own separate branches, merge changes and resolve conflicts, dig through the logs and many other options—everything is on hand and does not require you to use additional tools.