When you are new to Salesforce and SF DevOps, often, people may tend to take advantage of the change set mechanism for deploying the Salesforce orgs. Even though this can work out well, with this method, you do not have a reliable source control approach that can store and effectively manage the development code set. There are many certain benefits to this approach, but first, let us explore a significant limitation of this approach to be known. Once you know the benefits you can get the most out of it when you use it.
Missing the version history
In case of any problems, we tend to miss the simplest ways to roll back the target org. The team members can easily overwrite one another’s work with some conflicting codes or configuration changes. There is no easy way for the users to merge or clone the changes from various sources and orgs for deployment to target org. So, here we discuss the means to understand how Git will help you in the deployment process. To do this, we may use the Git lab and also breakthrough the pipelines. Further, let us explore the IDE configuration, which will make the task easier for the DevOps administrators.
Configuring the IDE for development
To start using the Visual Studio Code for the Salesforce development process, you must install only very few tools, which all come free of charge. If you explore the Marketplace Extensions, you can find various extensions and detailed documentation as a part of the extension bundle. You can further dig into those and check out the GitHub repository for more extensions, which is also an open-sourced project.
From the Production Org, you may proceed to create the two Sandboxes as development
- Develop and
- Release
After this, you can also create a new project in the Visual Studio Code for development.
To manage the deployment properly in the production sandboxes, you have to create a repository. The project branch structure should be as follows:
- Master – production branch
- Release – a brand of the UAT, which represents the production candidate.
- Develop – it is the development branch, which ideally represents the integration test line. That must be mounted at the Develop Sandbox.
- HotFix – the fixes make in the production direct.
To create your custom project in the Visual Studio, you may use Org Picker to the Develop Org and the option of Org Browser or Use Manifest to retrieve the source from default org. Next, deploy the source to the default org.
Create the developing against the non-source-tracked orgs, open VS Code editor, and go to the Command Palette to run SFDX by choosing Create Project with Manifest. Next, you can click on the Org Picker At the sidebar of the code editor. This will open a command palette from which you can choose the command for authorizing an org or Dev Hub or create a new scratch organization. You may also do the same by selecting one from the list of the authorized orgs given.
If you are developing the project in VS Code for the first time and have not authorized org before, then you can see the default message, which says, ‘No Default Org Set.’ After providing the org alias, next, you can get a browser window. Just allow access and log into the org to get back to the VS Code window. Here, the Org Picker will show the alias provided while you authorize the org.
After getting connected to the development sandbox in SF DevOps SDLC, next use package.xml to retrieve metadata from the org. When you run the SFDX: Create Project with the command ‘Manifest,’ package.xml file gets created. Just add different metadata types as you want to retrieve this file. To know how to work with various subsets of the metadata in the package.xml file, you can explore the Sample package.xml in the Developer Guide of Metadata API. There are also plugins available for VS Code to manage the package.xml file simply.
Another thing to note is that the model of Org Development does not track the changes to the org automatically. So, you always need to keep track of all changes you retrieve. Retrieving the source from an org may overwrite the source file local versions. While you retrieve the source from a given org, you could also enable. The conflict detection between local metadata and the given org.
Manifest For development:
In VS Code explorer, you can do the right-click at Manifest and choose ‘Retrieve the Source from Org.’ With this file open, go to the Command Palette and just run the saved file.
Source File For development:
In the editor, click on the directory or source file for choosing “Retrieve Source from Org.” With the source file being open, click on the editing panel and select the file to run it.
While you select an item to retrieve the source, only the nested items existing in the directory structure are retrieved. Say, for example, if you try to retrieve the source for the classes folder. Then Apex classes which are existing at present in the directory get retrieved.
This command will not retrieve all given Apex classes in the org but updates the classes which already exist in that folder. If you have to retrieve new Apex classes, add that class or all the Apex classes to package.xml file. And also try to retrieve the source by using a manifest file.
To bring code into the release branch, you can merge by using the merge request. Similar to Develop as discussed above, in the release branch also, the pipeline remains the same. We discussed above the simplest way to create an increment method for deployment directly. In the No-Production environment using continuous integration. We have primarily discussed the No-Production Orgs only in this article. In the forthcoming articles, we may cover the production org too. This will help out all those who are looking to implement new aspects to their business for better results.
