Vscode Sfdx

[Annegret Haldiman]

Undernormal circumstances, when you're starting a new project, the SFDX commands in the command palette are the ones I'm getting now... all about starting a new project. But then when you have a project, the palette commands change to include the full set of sfdx commands. What "tells" VSCode that info?

LATER...I opened a new VSCode window and ran the SFDX: Create New Project command, and it worked to create a new project. However, once the new project is created, I would expect the expanded set of SFDX command to show up, but they don't.

When I uninstalled VSCode, then reinstalled and opened the app, it knew to open the project that I had most recently worked on. That told me that uninstalling wasn't really clean. I was dumping the app from the Applications folder, as well as the .vscode/extensions folder, but there had to be more. That search led me to this thread.

If Connected Status has a value like RefreshTokenAuthError instead of Connected for Connected Status, just follow the steps to create a new alias, but when you set the alias, be sure to set it to the same alias that was already in use.

I discovered this when trying to debug why CumulusCI suddenly (as in, within the last two weeks) seems to have stopped letting me jump between Git repositories on my computer, deploying code from both of them to a single scratch org with cci commands.

So if I work at a company with 3 production orgs (one for the IT team, another for a sales team, and a third for a service team), I might have 6 folders under c:\git_repos\sf\, and all of my project folders actually go into one of those:

I also need to create a hierarchy of empty folders until a folder called c:\myfolder\force-app\default\ exists, because I told sfdx-project.json that it would exist. (Otherwise, commands like sfdx force:mdapi:convert fail, and I like that command.)

(Whenever I get an ERROR running force:org:create: This command requires a dev hub org username set either with a flag or by default in the config. message, I probably forgot to set a value for defaultdevhubusername in c:\myfolder\sfdx-project.json.)

When Salesforce DX was released, it was like a light appeared at the end of the tunnel. We would finally be able to work with CI/CD with Git and Pipelines, as it has been the standard for the past 10 years with any other technology!

This meant we had to script, script, and script over again (in Bash, Groovy or JavaScript, depending on the weather and mood), until efficiently reducing the essential manual operations, and reaching an acceptable state for the CI/CD Pipeline. The pipeline with its custom scripts had to be directly maintained in the project repository, which was efficient but time consuming.

But as we did not want to have to maintain scripts on each client repository. That inspired the idea to package an open-source engine that would be used everywhere, and repositories would only contain the configuration applied by the engine.

Salesforce DX plugins are usually used via the command line, and some of our Business Consultant colleagues were not happy. That was because they were not used to command lines. So we decided to create an UI to work with clicks, not command lines. That is how we got started with the Visual Studio Code Extension for sfdx-hardis.

In this diagram, I am giving you a before and after look at how introducing a devops pipeline changes Salesforce release management. In our case, we introduce a set of activities which make up the continuous integration and continuous deployment (CI/CD) process. These activities are run on a scripted command server that orchestrates the entire process.

It has been made to assist users by prompting inputs and questions when necessary, and displays in logs every background command so techies can see what is run behind the scenes in live.

Most of the configuration is in a single YAML file in your repository, with enhanced documentation and auto-completion while editing, and its content is usually directly updated by sfdx-hardis configuration commands.

The scratch org is a source-driven and disposable deployment of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with different features and preferences. You can share the scratch org configuration file with other team members, so you all have the same basic org in which to do your development.

Scratch orgs drive developer productivity and collaboration during the development process, and facilitate automated testing and continuous integration. You can use the CLI or IDE to open your scratch org in a browser without logging in. Spin up a new scratch org when you want to:

To ensure optimal performance, your Dev Hub org edition determines your scratch org allocations. These allocations determine how many scratch orgs you can create daily, and how many can be active at a given point. By default, Salesforce deletes scratch orgs and their associated ActiveScratchOrg records from your Dev Hub org when a scratch org expires. A scratch org expires in 7 days unless you set a duration when you create it.Scratch orgs have these storage limits:

Select the default scratch org definition file which is already created for you unless you want some extra features automatically enabled in your scratch org. which we already created above..

You can open the sfdx-config.json file where you can see the defaultdevhubusername as well as the defaultusername of your org which is linked with the current project as shown below:-

Apex PMD is also the name of the VSCode plugin. It enables VSCode to use PMD to detect and notify issues in your Apex code. The plugin includes a default setting which works plug-and-go and facilitates you to get familiar with this tool.

This extension allows you to use VSCode UI to select metadata files, and then automatically generate the package.xml file content for you. It saves the hassle of remembering what metadata file types map to what XML format. A really neat tool.

When you start a collaborative session, others can join and view the context of the workspace in their VSCode editor. This means they can read the code without having to clone a repo or install any dependencies your code relies on. Moreover, they can use rich language features, such as Go to Definition or Peek, to navigate within the code.

Some of its features:

1) You can get quickly the code coverage of your classes and check the covered/uncovered lines for any test method.

2) You can open the metadata in salesforce in the browser directly from the XML file in vscode!

3a8082e126