Release management with Copado, cloning fields and more in the Bloom R16

It seems like this would be the best moment to update our release names from Bloom and Blaze to something new, as we're starting a new iteration of significant updates to The Welkin Suite IDE. It would be even somehow nicer to release something like that on the 1st of March as a sign of a spring and something new and warm...

Well, we haven't done either of this  But what we've brought to you is a couple great updates for release management (including integration with a great service from Copado), declarative development and other changes across the IDE. Just take a look.

Built-in Copado support for better and easier release management

Development is not only about development... Wait, no, it really is about development, but also we cannot run away from the fact that change management is tied up very closely to it. We not only write code, or configure sObjects and automations in Salesforce - we also implement new features, improve existing ones, or fix issues. Usually, to manage all of that, we'd have a task tracking system to track the progress of our work, and to keep the team and stakeholders updated about the progress. Then on top of that, we'd also ideally have some kind of release management software or service that would help us properly deploying our changes between different environments: developing on a dev sandbox, passing acceptance tests on a staging sandbox and, later, deploying everything to production - sounds like a plan, doesn't it?

And there's a great chance that you might have already used a great service, which is offered by our friends from Copado that incorporates a lot of this capabilities under one roof (doesn't it sound similar to The Welkin Suite's idea?). If you haven't tried yet - go for it, they have a free trial and you won't lose anything.

Anyway, we felt that we need to enable your working with Copado directly from the IDE - maybe not everything right from the beginning, but at least the most common or important tasks for your daily development work. Let's see what you'd have in The Welkin Suite Blaze R16 for this!

As you'd expect from The Welkin Suite - we have one more panel exactly for your actions with Copado. You can open it using the 'Main Menu → View → Copado tasks'. The first time when you'll see this panel - it will not be as good as what you see on the screenshot above, as you will need to connect TWS with your Copado-enabled organization - to do this just press the login button in the toolbar.

In this very simple wizard, you need to enter your Copado-enabled org (or use OAuth for this) and specify your API key - you can get this if you'd login to the org, open the 'Account Summary' tab, and switch to the 'API key' subtab. Once this is done, your user stories will appear in the Copado panel with the following details:

• 'User story' - Name or key of the user story. This is a clickable link that will open the story in your browser so you can look for more details;
• 'Summary' - Summary of the story, so you'd not forget what is it about;
• 'Story points' - Story points estimation for the story;
• 'Status' - Current status of the story.

Both Story Points, and Status fields are editable directly from the panel, so when you need to update these fields - just double-click on them in the corresponding row, and make the changes you need.

In the toolbar you can find the following items:

• 'Login' or 'Logout' button that is used to login to your Copado-enabled organization where all the release management magic happens;
• Project selection dropdown;
• 'Start tracking changes' / 'Restart tracking changes' button that is used to track changes that you do within the IDE (see below in more details);
• 'Stop tracking changes' - to stop tracking changes;
• 'Show difference' - to see the changes you've made since you started tracking changes;
• 'Commit' - to commit your changes to Copado;
• 'Upload changes' - to apply changes that you've made on stories in the panel;
• 'Refresh' - refreshes the list of tasks from Copado.

When you start tracking changes, The Welkin Suite makes an internal checkpoint for a corresponding project. The tracking process won't be stopped if you switch to another project or close the IDE, so you can keep working on your task for a while, and still know what was changed since the time you've started. You should also take into account that the IDE only tracks changes according to local files, so if someone changed a class on your development org, but you have not pulled it to your project - this change won't be reflected.

At any moment you can check the difference, and see a list of changed files with an inline diff view-- this way you will see the exact changes in those files.

When you hit the 'Commit' button, you will see almost the same window, however with the option to enter a commit message for your commit, and an option to select what exact files should be included into the commit.

So now with all these options, your flow when you start working on a task might look this way:

1. Select the correct task in the 'Copado tasks' panel, and update it's status to the one that's used in your team (we assume it's something like 'In Progress')
2. If needed - link the user story with Org Credentials, according to the org where you're going to work on the user story
3. Start tracking changes in The Welkin Suite
4. Do your great stuff
5. Once ready - commit your changes to Copado (and linked Git repository) directly from the IDE
6. Stop tracking changes, if you don't need this anymore

Tracking your local changes since a checkpoint

You might say that the Copado integration is already more than enough for what The Welkin Suite has released about changes management over the last 3-4 months, but we want to add one more handy feature. What for? Let us show you.

The new 'Tracking Changes' panel provides you a handy way to track what you've already done since some certain point in time - it can be a start of a new task, fix for a small bug you've spotted while working on a new feature, Monday morning, or anything else. You can do this by selecting a project in the panel and clicking on the 'Start' button - the IDE will create a tracking point and will prompt you to name it, if you don't like a default name, of course 

Once this is done the IDE will remember that current state of the project and will show you a summary of what was changed since that moment, whenever you hit the 'Reload' button on the toolbar.

So if we'd use a new task scenario from the example above - once you start a task you can start tracking your changes. Since a task might be a big one - you can spend days or, even, weeks working on it, but The Welkin Suite won't forget where you have started, and it will remind you about what you have changed since that moment. Once you're done with it, and ready to show it to the world, you can use the list as a hint for a changeset or, much easier, just click the 'Deploy' button on the toolbar  Of course it won't deploy everything on its own, but it'll be really faster than before.

The 'Deploy' button will open the standard TWS deployment wizard, however when you'll get to the step where you need to select what exactly needs to be deployed - everything you've worked on will be already selected by the wizard.

At the moment you can have only one checkpoint for a project, but let us know if you'd like to have an ability to have multiple checkpoints.

If you have any ideas about how else this list of changes can be used - drop us a few words and we'll be happy to make your ideas real life 

Max Lazy Mode: Modifying sObjects using the new 'Clone Fields' option

We should replace 'Lazy' in the header above to that of 'Efficient' as it's impossible to find anything negative in automating routine tasks and saving your time for something more interesting,  where you can both resolve complex issues and train your brain. This is why you can now find a new magic button in the sObjects Inspector on the 'Fields' tab.

It won't be a surprise that after pressing that button, and, maybe, some more buttons the IDE will clone field(s) for you, however would you expect to get such a number of options on how to do this?

• You can select multiple fields to be cloned
• You can select how many times each field should be cloned into a target object(s)
• You can select one or multiple target objects, even the same one
• And, of course, you can search for fields and objects using filters - it's somehow quicker

After you hit the 'Clone' button, the IDE will modify the corresponding XML file(s) for target object(s) with the cloned field(s), so you can later fine-tune them using the regular XML editor or the built-in sObjects Inspector.

Having all these options provides you with a way to speed up many common tasks, just to name a few:

• Duplicating a set of fields from one object to another - simply select the needed fields and copy each of them, 1 time to an another object
• Creating repetitive fields (e.g. different phone numbers on a custom object or those not-looking-good-but-still-inevitable 'Account 1', 'Account 2', 'Account 3', etc.) - select a field and copy it multiple times to the same object
• Create repetitive sets of fields (e.g. multiple addresses, containing Street, City, Zip, Country, for example) - select couple fields and copy them multiple times to the same object

Isn't it easier?

Of course, after bulk changes to your objects you'd want to modify the FLS and Layouts for them, so just switch to the corresponding tabs in the sObjects Inspector where there are a lot of 'bulkified features' already!

But wait... Don't leave the 'Fields' tab yet - check out the embedded formula editor

We'll never get tired saying that sObjects are among the most important things in Salesforce development, and as we talk with more and more people around, we are more sure that whether you like to or not, you'll probably have to deal with sObjects very often. This is why we have a huge backlog of different improvements for the 'Fields' tab in the sObjects Inspector.

Today we are bringing the great experience of the built-in code completion for Salesforce expressions (that you might have seen in our Validation Rules editor) to Formula fields and to the default value parameter for all fields.

So starting from the Bloom R16 version of The Welkin Suite you will be able to quickly modify formulas or default values without going to the Salesforce UI (and doing lots of clicks there) and without doing raw XML editing!

Other changes

In the last winter version of The Welkin Suite for Windows, we also made additional changes to improve some of the functionality and to solve the issues.

You know... fixing or adding something new to a functionality that is already present in the IDE for a while is just a great way to highlight it for you once more, just in case you haven't had a chance to look at it previously  Today this kind of feature is an ability to open some items of your TWS project (e.g. org via Solution Explorer, Visualforce page again from the Solution Explorer, Lightning Application or Visualforce page from the built-in previewers, Layouts or sObjects from the sObjects Inspector or Admin Panel, etc.) in your browser directly from the IDE - previously you've still had to enter your org credentials in a browser, but now thanks to one of our users who almost wrote the code for us (no, but he've pointed us to a right help article in Salesforce) - you won't need to enter your SF org credentials in a browser whenever you open something from the IDE.  At all.

A great part of this was dedicated to the Local History functionality. You may not have noticed these changes, since in most cases they are internal, however, they solved some known issues. For example, such issues as some TWS crashes, cases of the failed pulling or building to your organization that were caused by an absent initial commit after a project creation. Of course, if you would be faced with any of those issues or new ones, please let us know and we will continue our work on solving them.

The next important change is related to an issue when your sObjects could be absent in a list of code completion suggestion. A reason for this was that after some changes in your project, the IDE couldn't get access to the cache file that stored all the data about objects for using it in generating a list of completions. We have changed an existing approach a little bit, and now you will be able to use the code completion fully.

Also, we have solved TWS crashes from the Bloom R15 version of the IDE, which occurred when refreshing the Code Coverage data.

Our developers have added handling of one more error from Salesforce that was caused by a temporary lock of organization's administration setup. In this case, TWS showed a message that file had been modified outside the source editor when you built your changes, however, these changes couldn’t be saved due to the lock. Beginning from the Bloom R16 version of the IDE you will get an appropriate message about what is going on

Also, we have solved issues related to the work on previewers in Salesforce DX projects. The Lightning previewer is still absent for SFDX in the IDE (and we will implement it soon, promise), however, in the previous version of TWS you could see a template for it. Currently, we have removed it to make no confusion for you. One more fix is related to the settings for Lightning and Visualforce previewers in Options - no changes could be saved and this caused TWS crash that won't happen anymore.

Continuing with Salesforce DX projects, it appeared that one of our favourite Apex-related features - ApexDoc was not previously supported by SFDX projects and thus you've missed the easiest and the most comfortable way to document your code. From now on the IDE will do everything it should about ApexDoc in Salesforce DX projects as well - both generating Apex Doc headers and showing the details as a part of the code completion!

Full list of changes

Features:

• Implemented the support for Copado for release management
• Implemented an ability to track changes in TWS project
• Added an ability to clone fields in a frame of one or several Objects
• Added the ApexDoc support for Salesforce DX projects

Improvements:

• Implemented the formula editor for fields that have a formula type in the SObject Fields inspector
• Made internal changes to improve the Local History functionality
• Updated 'Open in browser' commands to use the 'frontdoor.jsp' from Salesforce

Fixes:

• Fixed the issue when sObjects were absent in the code completion suggestions
• Fixed the crash of TWS on refreshing the Code Coverage data
• Handle a temporary lock of organization's administration setup during a build
• Removed the template of the previewer for Lightning Components and Application in Salesforce DX project since it is not implemented yet
• Fixed the crash of TWS when changing visibility settings for Lightning/Visualforce for SFDX project
• Fixed the issue when a cursor wasn't redirected to a line with an error in a SOQL query after double-click on an error message in the Error list
• Fixed the issue when an empty inner class was absent in the list of code completion suggestions and it had improper state in the code outline