Sales Systems exists to support the GitLab field organization by providing reliable, scalable, and intuitive technology platforms for everyday use. Primarily working on Salesforce.com and its related business systems, our goal is to constantly deliver value in the form of features to our end users. We also act as the connective tissue between business and technology, gathering requirements from our internal customers, designing the technical specifications and executing on the delivery of the solution.
Team Skill Sets
Below is a list of the different technical skill sets found on the Sales System team. Note: A Sales Systems team member might be using a mix of the following skills sets at any one time.
Role
Expertise
Business Systems Architect
Project lead in charge of gathering business requirements from customers and developing them into technical specifications.
Your SFDC Dev Environment is correctly pointed at your SFDC Dev Sandbox
You have cloned our Git repository into your local Sandbox working directory.
You are working from a GitLab issue with clear technical specifications that deliver on the agreed business requirmenets.
Change Managment Steps:
Make sure you start on branch master and git pull.
Create a new branch, giving it a name that ties back to the issue: git checkout -b "SalesSystems-158".
If you are writing code, frequently push your changes to your sandbox using and SFDX: Deploy Source To Org on the changed classes, triggers or pages.
If you are editing configuration, frequently pull down your changes to your local environment using SFDX: Retrieve Source From Org on the changed objects or metadata.
Make sure to write and run a unit test for code, and for both code and config, test the changes by hand in the SFDC user interface.
When you feel your iteration is complete run git status to make sure the changed files are the ones you expected.
Add in the files you wish to commit with git add [filename] or git add * if you want to add all changed files.
Commit your changes with a relevant message: git commit -m "Fixing Apex CPU Errors".
Using the link provided by GitLab, open a merge request, make it a WIP:, and assign it to the Architect on the project.
Comment on the related issue with an @ to the project's Architect for review, providing a link to the merge request. (this automatically links the merge request to the issue)
If the Architect calls for a live demo, schedule the meeting and prep your sandbox to do a run through with the end customer.
If the Architect calls for user acceptence testing, make sure the assigned testers have access to the sandbox where the work was done, and schedule testing.
Once the solution passes, the Architect will remove the WIP: status and merge the change.
Once merged, package up all relavent files into a Change Set from your Sandbox to Production (or to a Staging instance if the Architect requests it).
Name the Change Set the same as the issue/branch: SalesSystems-158 and push to production.
Once the Change Set arrives in production, validate it. If there are any errors, go back to step 3. If steps 3, 4, and 5 are followed errors at validation should be rare.
Once the Change set validates, ping the Architect to schedule the deployment.
After the deployment, perform any post deployment steps such as adding visibility to net new fields.
Confirm with the end user that the functionality is working as expected.
Create a merge request to our technical documentation adding the new feature or editing the features entry.
Before moving to your next task rebase with git checkout master then git pull. Always be pulling!
