dev zone

  • DevOps Centre

    The new Spring ’23 Release from Salesforce is almost here. And it brings with it a big change that will help Admins and Developers alike manage their environment setup. Let’s jump in ‘deep dive’ into at the DevOps Centre, released as part of Salesforce Spring ’23 Release.

    DevOps Centre – Now ‘Generally Available’

    Yes, Salesforce DevOps Centre hits the ‘GA’ (Generally Available) milestone in the Spring ’23 Release.

    This is potentially big news for a lot of organisations! Let’s take a step back and see why there is a lot of noise around this in the Salesforce community.

    Quick note: I am going to try and walk the fine line between dev and admin here in this post... I am aware some of these concepts will be very new to some people.  If this is you, please check out the Other Resources section at the bottom of the page.  Where I have tried to include a few links to help provide additional background/context.

    Brief history of Change Sets

    If you have any experience managing Salesforce as an admin or dev, you would likely have used Change Sets. They are ubiquitous with Salesforce. And have helped users move changes from one environment to another, without having to ‘redo’ the work manually.

    A change set in action

    For a long time now, a Salesforce user with appropriate permissions could prepare a number of changes in an environment, like a sandbox (eg page layout changes, new fields, custom metadata/settings, etc). And then use Change Sets to group these changes together and move them between various connected environments.

    It has been a very useful tool, but not without its limitations. Especially as the Salesforce platform rapidly expanded beyond ‘simple’ changes and products over the years!

    As development requirements progressed and orgs became more sophisticated, organisations looked for specific tools to manage their Continuous Integration and Continuous Delivery efforts (commonly referred to as CI/CD).

    Many organisations have also required the ability to not just deploy changes. But also track version history and changes made to elements within Salesforce.

    As teams developing/configuring Salesforce environments scale in size, Change Sets simply haven’t been able to ‘keep up’. Especially with some of the alternative methods to manage deployments now available to organisations. Dev tools now manage Salesforce components via Metadata API and integrate with platforms specifically made for this situation (eg Github Actions/Bitbucket Pipelines).

    Why ‘DevOps Centre’?

    This leads us to the problem Salesforce is trying to fix. Why is Salesforce is releasing the new DevOps Centre?

    Simply put, Change Sets are not ideal when dealing with complex releases. Having to rely on someone to manually track the changes (like field updates, page layouts, profiles, setup options, etc) and then add all of these changes into a Change Set, is an extremely cumbersome process.

    An example of a CI/CD pipeline for Salesforce (Source: SalesforceBen)

    This is why tools like the above mentioned CI/CD pipelines, actually exist in the first place.

    By integrating with a source control system (eg Github/Bitbucket/etc), DevOps Centre gives Admins/Devs immediate access to track changes made within an environment.

    Additionally, most orgs these days, have Admins and Devs alongside additional project support staff (like Business Analysts/Release Managers/etc). Using these tools and having a release governance framework, allows everyone to track the same changes included in release.

    Yes, there is a bit of a learning curve.

    Althought Dev teams are typically who would use a Source Control system, there is huge value in Admins learning how to use these tools too.

    Imagine being able to easily understand how/why a formula field was changed! Or avoiding two people updating the same page layout and losing the changes.

    Alternatively, if you have deployed a change set and need to ‘roll back’ a change because something has gone wrong. Having this version control/history available helps to restore your environment quicker.

    DevOps Centre – Setup

    Setting up DevOps Centre will take a little bit of time and planning. Especially if you are new to things like source control systems (primarily GitHub).

    There is a great guide on Salesforce Knowledge Centre, which covers enabling and installation through to managing your environments and how to troubleshoot issues.

    Overview of Features

    DevOps Centre works by utilising the ‘source tracking‘ feature of Salesforce DX. And allows users to ‘pull changes’ from a linked sandbox into a new work item:

    Source: Salesforce

    Track Changes & Work Items

    In this example, you can see the in progress changes to a number of elements from the sandbox (Karen CB1 Dev1). These changes include two profile updates, along with a new custom object and page layout.

    You then you can also view the Activity History, much like Activity History on an account/contact record, this section allows you to view the change history of the work item and even search for specific changes:

    To then help coordinate the environment management, DevOps Centre also allows pipelines to be setup. Imagine a pipeline, as simply a defined way to release things from one sandbox to another. Based of your change management governance, all changes can be routed through a pipeline to then be deployed into the appropriate sandbox/environment.

    Pipeline / Environment Management

    From the Pipeline screen, you can define and connect various sandboxes to the different stages of release management.

    Source: Salesforce

    Imagine each admin/developer works in a different sandbox to make their changes. Each person might do a Work Item for their changes in their sandbox.

    Then merge all the pending changes together into a single Integration/UAT environment, DevOps Centre integrates with GitHub to group all the changes to be released together. And then manages the deployment into the environment.

    Take a moment to imagine doing that via only Change Sets…

    Don’t other tools already do this?

    In my opinion, I will say DevOps Centre isn’t really unique in doing all of this.

    As mentioned above other tools have existed in the past, which do a very similar job. Though they have typically been focussed on developers, and less on the ‘point and click’ crowd.

    The benefit that I see with Salesforce DevOps Centre, is if your team uses GitHub (or similar) already for development you can now include your Admin team. This should reduce the learning curve that comes with GitHub for people new to version control. While allowing developers/users who already use Salesforce DX, for example, to continue to work with their repository/project.

    If you have everyone that configures/develops Salesforce all working in a similar way… When to comes to releasing new customisations/development, the process should be smoother for everyone involved.

    There is nothing more frustrating than updating a page layout or profile, only to have someone else overwrite your change and then you have to try and find out why/when it happened. Especially when you have to trawl through different versions of the same Change Set. 🙁

    DevOps Centre – Who can use it?

    This change applies to Lightning Experience in Developer, Professional, Enterprise, Performance, and Unlimited editions.

    As per Salesforce Release Notes: Salesforce DevOps Center hasn’t been tested and isn’t recommended for Government Cloud/Government Cloud Plus.

    Other Resources

    If you want a broader background on CI/CD, this SalesforceBen article covers a lot of the background and planning side involved with CI/CD and Salesforce.

    To get you started there is a great guide on Salesforce Knowledge Centre. This covers installation and initial configuration/linking to GitHub repository.

    There are a number of use cases available to read through, on the Learn Moar page for DevOps Centre – which was released when the beta trail started. This looks at use cases including developers and admins. And also how DevOps Centre can integrate into your existing way of working, if you work with third party dev tools.

    Additionally, Trailhead now also includes modules relating to DevOps Centre.

  • Getting started with VS Code for Salesforce

    So confession. I am like using and am quite comfortable using the IDE/Eclipse and even Developer Console when I do dev work. Have I used VS Code for Salesforce before? Nope! IDE is my go-to and I have been using it for a number of years…

    But as you may have picked up, Salesforce has been starting to push users to switch over to VS Code with the retirement of the IDE v2 beta in Spring ’18 release.

    Additionally to develop with features like Salesforce DX, you need to switch to VS Code. So let’s take a look at what VS Code is, how to get it setup and how to deploy your first class to a sandbox…

    What is VS Code?

    Firstly, if you haven’t heard of VS Code (or Visual Studio Code). It is a light-weight, open-source, code editor. And it is optimised for building and debugging modern web/cloud applications.

    The core features include:

    • Intelligent code completion
    • Syntax highlighting
    • Embedded GIT control
    • Support for debugging
    • Extendable via plugins/add-ons (which is how Salesforce comes into the picture)

    It is a free tool to download, and runs on most major Operating Systems (Windows, Mac, Linux). And isn’t based on Java, instead using the Electron framework to build cross-platform desktop support, essentially using web technologies.

    Most importantly, don’t confuse it with Visual Studio which is used primarily for .Net related programming languages and is only available on Windows.

    What’s behind the change?

    Well, the simple answer, is that VS Code was an easy platform to use, to give Salesforce the Command Line interface needed for Salesforce DX development via a VS Code plug-in.

    But personally I feel, there is a bigger motive behind what we are now seeing over the last year or two for Salesforce re: platform development (and features like Salesforce DX becoming available)…

    Most Dreaded Platform…

    See, historically Salesforce has been receiving overall negative reviews from Developers, and has typically featured in the top 5 (if not the top position) of ‘most dreaded’ lists from yearly developer surveys on sites like StackOverflow.

    As seen in the 2015 Developer Survey, Salesforce achieving the infamous achievement of ‘Most Dreaded’ platform.

    The surveys since don’t fare much better, including the latest 2018 survey with Salesforce in the top 3 ‘most dreaded’…

    Personally, when talking to a number of .Net developers over the years, I am not surprised by these results. Even though APEX is similar to other languages, there are a number differences between developing for a cloud-based platform like Salesforce vs a .Net application. And there needs to be…

    But things like Salesforce governor limits, take on a huge focus when developing for Salesforce (hello, bulkification), and it does force you to think differently about how you solve a problem. But I digress…

    Additionally, the fact most developers don’t use Eclipse as an IDE… But instead prefer to use VS Code as a development environment, we can start to see why Salesforce is heading in the direction it is:

    VS Code ranks as #1 favourite Development Environment for Web Developers.

    Additionally we are seeing a renewed focus from Salesforce on improving the overall development experience over the last few years. Features like Salesforce DX/scratch orgs, Lightning Components (using more standardised web-development languages, eg Javascript) and now with Spring ’19, Lightning Web Components.

    Salesforce is clearly making a play to smooth the development experience for developers, primarily for other web-platform developers, who aren’t familiar with Salesforce.

    Why? Well, in my opinion by implementing a way to allow someone to develop on Salesforce, but with no specific Apex/Visualforce knowledge, they are growing the overall developer market and making the platform more flexible overall for developers.

    What does VS Code offer Developers?

    So that is it for the history lesson part of this write-up! Now let’s take a look at what VS Code might offer us Developers who are used to IDE…

    The main take-aways for me out of the video are:

    • Track changes easily to source XML
    • Replay Debugger, being able to ‘step through’ the code now and see variables at runtime, all based on the debug logs. This is relatively new thing for Salesforce, but is common in other development languages. And will streamline how you handle debugging of processes
    • Support for Scratch Orgs vs ‘normal’ Sandboxes/Production
      • Scratch Orgs give you a disposable/throw away development environment and can be spun up instantly. (Think Salesforce DX).
      • Package Development Model, is similar to what you are probably used to in IDE, allowing you to push/pull into development/trial sandboxes or production environments.

    How-to Guide: Getting Started with VS Code

    So let’s go…

    When I was trying to install and get my development environment setup I had to jump around to multiple sites to try and figure out how everything works together. So I am trying to collate this all into one spot as I learn myself…

    But please note, as I am going through and teaching myself about VS Code and writing this, there may be quicker ways to do things. If you have any of these tips, please feel free to add them in the comments section at the end of the article!

    Welcome to VS Code...  Your new development environment.
    Welcome to VS Code… Your new development environment.

    Gettings Started #1. Installing and setting up VS Code

    Downloading and installing VS Code

    First up, you will need to download VS Code. I will assume your machine can handle VS Code… And it is free and available to download for Mac/Windows/Linux from here.

    Setup VS Code for Salesforce

    You will also need to install the Salesforce CLI package, as the Salesforce extensions for VS Code (the next step) require this package to be installed on your machine. So jump over to here to download and install it.

    Salesforce Extensions

    The final step to getting VS Code up and running, and before we start on our first project, you will need to also install the Salesforce Extensions for VS Code.

    These are freely available in the VS Code ‘marketplace’ (think the App Exchange for Salesforce, or Chrome Web Store for Chrome Extensions).

    Click here, and click the green ‘Install’ button. You should then be prompted to open the link in VS Code. You will then see another pop-up with ‘Install’ button. Click it, and then VS Code should install/restart.

    Other Extensions

    There are a number of other Salesforce related extensions available. I won’t cover them here, but you can easily search the Marketplace and find other relevant extensions/packs.

    This is one advantage of being an open-source platform, anyone who wants to can develop and share an extension/plugin if that wanted to…

    Learning Basics of VS Code

    To learn the basics of VS Code, Microsoft has a ‘Get Started’ section on the VS Code website. These video cover the basics of:

    • Navigating around VS Code
    • Debugging
    • Using Intellisense (the code completion/suggestion feature like Content Assist in Eclipse)
    • Version Control (using VS Code with GIT)

    My first impression was a little confronting. This might not be the case if you are use to command line development (CLI), but after coming from Eclipse where most things are point and click, it was a little bit of ‘gee, what do I do now?’

    The main thing to learn and start to get comfortable with is the Command Palette, as this is how you will navigate and access the commands within the tool:

    command palette
    VS Code: The Command Palette

    I would urge you to take a look at the Tips & Tricks page from Microsoft on VS Code too. It includes print outs of the keyboard shortcuts and a number of other useful details.

    Getting Started #2. Creating your first Project

    There is a useful Wiki published on the Salesforce DX Github page, and it outlines the types of projects you can work (scratch orgs vs developer/trial sandboxes/etc) and how to get started with the various Command Palette commands.

    The two models you should be aware of (sourced from the below guide on GitHub) are:

    • Org Development Model – which is similar to what you are probably doing now if you use IDE. And is where you connect to an environment (eg Sandbox, Developer, Trial, or Production org) and then develop/deploy code directly into that environment.
    • Package Development Model – is the second type of development model and this is where you would ultimately connect to a scratch org for development. To read more about this, click here.

    The commands you use in the Command Palette will depend on the development model you are trying to setup and code with… There is a full guide for both development models here.

    But for the purposes of this post though, I am going to setup and connect to a Developer Sandbox via the Org Development Model.

    Open the Command Palette

    To get started, open the Command Palette (on a Mac, which I am using press CMD+SHIFT+P), and in the Command Palette type in:

    SFDX: Create Project with Manifest 
    Command Palette: SFDX: Created Project with Manifest

    Then, the Command Palette will ask you for the name of your project, so type in a Project Name and press enter. I am just calling this ‘My First Project’ for this guide…

    Command Palette: Enter the Project Name

    Then you should get a pop-up window asking you to confirm the location to save it on your local machine. (This is similar to the Workspace location in IDE).

    In the pop-up window, confirm the folder location and click ‘Create Project’:

    Choose your Project folder location

    You will then see your Project open in the Explorer (on the left hand side):

    Explorer: ‘My First Project’ is now ready to start…

    Getting Started #3. Find your sfdx-project.json file

    This file should have created as part of the project, and is where you store the configuration information, like which environment you want to connect to.

    You can read more about this file here or here.

    For this demo, I will update the URL to login to a sandbox to, and save the changes to the file:

     "sfdcLoginUrl": "",
    Project: Editing sfdx-project.json file

    Gettings Started #4. Let’s get connected…

    We need to start the process of essentially connecting and logging in to the environment we want to login to.

    Now, open up the Command Palette again and type in:

    SFDX: Authorize an Org

    As you type, you will now see a number of new SFDX commands available too. But for now, just select the Authorize Org option and press enter.

    Command Palette: Authorize an Org

    The Command Palette will then prompt you for which environment type to login to. You can select ‘Project Default’ as we already updated the sfdx-project.json file already.

    Setting up a Project: Select Project Default

    And then you will also be prompted for an Org Alias, you can press Enter and accept the default name, or specify a custom alias.

    Setting up a Project: Select an Org Alas

    Now, VS Code and the Salesforce Extension will open up your browser and take you through the normal login flow. In this example, I have Lightning Login also setup (just to demo that this also works).

    As you go through the login, if this is the first time for the environment you may also see a ‘Global Connected App’ authorisation, just click Allow.

    Meanwhile, back in VS Code, you should see a little pop-up on the bottom right hand side now confirming login has been completed:

    SFDX: Authorize an Org successfully ran.

    Getting Started #5. Retrieve your Source

    Now we are authorised, we can go ahead and look and downloading our source components.

    You will need to first check you package.xml, which is where information on what to download/retrieve is stored. You can find the documentation on the .xml file here.

    But imagine this step, being similar to IDE where you select which components you want to download from the environment.

    And keep in mind, this step is only for when you connect to a developer, trial, production environment. If you go and use scratch orgs, you won’t have to do this step.

    In the Explorer under your Project, find the folder ‘manifest’. This is where you will find the Package.xml file.

    By default, it includes the APEX components, Aura Bundles and Static Resources, but you can add to it if you wish.

    Package.xml contains what elements you will retrieve from the server.

    Now with the Package.xml ready, you can commence the download/retrieval of the elements.

    Here, instead of using the Command Palette, you will need to right-click on the file in the Explorer, and select the option:

    'SFDX: Retrieve Source from Org'
    Explorer: Right-click and select ‘SFDX: Retrieve Source in Manifest from Org’

    Gettings Started #6. Work with your code…

    You will get another little notification once it has completed downloading, and now you can navigate to the code!

    Navigate via the Explorer, to force-app -> classes -> find the Apex Class you want to work with and double click on it to open the editor. Then this part should feel very similar to Eclipse.

    Use Explorer to navigate to your Class/Trigger/Aura/etc to start working with it.

    Now you can start your coding. To use features like Intellisense (the auto-suggestion feature), you can select CTRL-Space (on Mac, though I assume similar on Windows) to up the pop-up:

    VS Code: Intellisense auto-suggestion/completion for your code

    As you you coding too, you will see in the bottom left hand side of the screen an Errors and Warning notification. You can simply toggle the Panel to display by clicking on the icon (or CMD-J on Mac).

    This Panel, then displays the Problems, Output, Debug Console and Terminal (if you need them).

    Problems via the Panel will look very familiar to you if you have used Eclipse (or Developer Console):

    Panel: Displaying Problems, like syntax issues / etc

    Gettings Started #7. Deploying your code back to Sandbox

    And finally, when you are ready to push the code back to the server. You can right-click on the class again, and then select ‘SFDX: Deploy Source to Org’.

    SFDX: Deploy Source to Org

    Getting Started #8. Deploying to Production?

    Salesforce don’t recommend using the above ‘Deploy Source to Org’ to move things into Production. Instead they advise developers to use the Packaging feature.

    For now, this is just a how to get started guide… But if you are ready to move your code to a Production environment, please read more about this over here.

    Extra Reading: Migrating from IDE to VS Code

    The final guide for you, is if you want to migrate your workspace and projects over from IDE. into VS Code

    Salesforce has included instructions you can follow, to migrate your packages into VS Code. To read more, click here.

    Wrapping up

    So this is just the start. But we have now connected to a sandbox, worked with our first Apex Class and Deployed it back into the Sandbox.

    There are a lot of other features which will be covered in another post shortly (like working with source control/repository and debugging). But for now, happy coding!

    And as I mentioned at the start of the guide, if you have any shortcuts / tips or suggestions, please add them in the comments below!

    Appendix: Other Resources

    Video: VS Code for Salesforce Developers
    Video: VS Code IDE for Eclipse Users

Back to top button