Question about Unorganized Org/Sandboxes

Question

So I'm fairly green when it comes to development. I left a company that had an insanely structured enterprise Salesforce organization with many teams and joined one that I'm realizing is pretty much the polar opposite. I'm used to having multiple sandboxes and orgs that to my limited understanding are all synced with Azure. We used Source Tree for version control and had sandboxes for Testing, Development, Dev Ops, Staging, and probably two other cases that I am not familiar. Everything was regularly setup so there was main branch --> sprint branch --> your branch that gets merged back to sprint branch. Once merged everything was tested heavily by another team in a testing sandbox and then staged. It took about a month and a half or so for things to end up in production.

Current company seems to just have one sandbox between devs and production. A number of devs are not using VS Code but told me to use it and would probably want me to show them how. I'm a bit confused since I am green that this situation exists and I can't seem to get some of the answers I feel I need. Here are my assanine questions:

If there is just one sandbox between me and the production org, should I be pulling down the whole repo into VS Code every time I go in to edit something in code or should I just download that whole org once and then pull down individual components as needed?

I am used to having VS Code kinda laid out for me. My laptop arrived ready to rock and had a bit of mentorship when it came to this. I am wondering how to set up version control in this situation. If there isn't really any organization and every developer is pushing to the sandbox then gets pushed into production (which is insane but seems how this is working) should I still be creating branches and merging and what tools outside of the terminal included in VS Code should I do some research on?

In prior job admin fixes were done in the sandbox, meta data was pulled into the repo, and then everything was commited and pushed up to a branch. Here I believe that admin fixes are just being done within this sandbox and then pushed to production. In that case do I need to pull retrieve this org every time if I don't know what the specific admin fixes are on a regular basis due to the fact that I may not have all of the metadata?

Do you have any ideas/resources for bringing this organization into the 21st century or resources for a junior to really wrap their head around this other than "Trailheads".

It feels like there is a lot of room for me figure out some real infrastructure here to make things move more smoothly so I would love any recommendations you all may have. Feel free to crap all over this as well. Looking forward to your responses.

Answer 1

This is a tough question as it covers a lot. Not to mention the unknowns:

• Complexity of your org
• Distribution/roles of your team/members
• What tools you have available (paid, specific tools you have to use, etc)

I'll try to cover some good starting points, but you'd have to ask more specific questions as you undertake the journey and hit roadblocks. Or, if it's more open-ended/discussion-based (which isn't best-served on this site) - you can look to leverage trailhead groups or other sites (reddit, sfxd discord).

In short, I would particularly recommend going through the Salesforce Developer Tooling Learning Map. It contains most of the below and a lot more resources for planning, coding, testing, and deploying in the whole process.

---

Several important notes:

1. Get others invested in doing this with you instead of a one-person show.
2. It's tools, technology, process, and people that make the DevOps process work.
3. You can't change their process overnight
4. This change needs to be planned for - ex. plan for "learning", slower initially
5. You need to time to learn. As you mentioned, you're green to this and it sounds like you may be the only one familiar with how well it looks when effort is put to get behind this.

Some learnings/trailhead everyone should start with

• Learn Why Version Control Is Important for Team-Based Development
• Development Models
• Getting Started with Salesforce DX series

SalesforceDX is the Salesforce Developer Experience (DX) which covers the environment/tools at your disposal to develop on the platform. Some highlights/benefits include:

• The ability to apply best practices to software development. Source code and metadata exist outside of the org and provide more agility to develop Salesforce apps in a team environment. Instead of the org, your version control system is the source of truth.
• A powerful command-line interface (CLI) removes the complexity of working with your Salesforce org for development, continuous integration, and delivery.
• Flexible and configurable scratch orgs that you build for development and automated environments. This new type of org makes it easier to build your apps and packages.

In general, the setup can be as simple as:

• Salesforce CLI
• VS Code
• Your Source Control provider (ex. Github, Bitbucket, etc).
• Enable Dev Hub Features in your Org (necessary if using Scratch Orgs)

As you noted, they only have one dev org. See if you can spin up others, do they have a full sandbox, partial sandbox, etc. In the end, as you noted, source control (your repository) should be your source of truth as your primary goal.

---

Most of what I recommend above is to start learning so you and your team can decide what path to take forward. There's more drastic changes (package-based development with scratch orgs) and there's smaller, but still value-driven, changes you can make (source control being source of truth). Others may not want to put in the work, but source control/git/devops is an opportunity to improve your experience as well as learn new, valuable skills as orgs get more and more complex.

I'd say your first steps, simply put, are:

1. Take time to learn the tools and new concepts
2. Decide on the change you want to make
3. Start making progress towards that goal.
4. Set milestones