Create Salesforce workspace from GitHub repo

github
salesforce

#1

Does anyone know how to create a workspace from a GitHub repo that will then be used to code against a Salesforce org?

I can create a workspace for a Salesforce org. I can create a workspace from a GitHub repo that I have access to. How do I do both so that my edits to the Salesforce org can be saved to GitHub?

Thanks for the help.

Cheers!

John


#2

Hey John,

Great to see you on the community!

Check this out:

I put this together recently to describe a workflow of creating new code in a Sandbox, using bitbucket for source control, and then deploying the code into Production. Hope it’s useful. Please let me know.

One EDIT, you no longer have to create the meta-xml files as I do do in the video as Cloud9 does this automatically.


#3

@Jeff_Jobs - Thanks for that. It gives me enough info to try somethings. I appreciate it. Cheers!


#4

@imjohnmdaniel - Glad I could help!


#5

@Jeff_Jobs Hi Jeff, using this method, is it possible to deploy destructive changes using descructiveChanges.xml? I’m looking for options to deploy deletions in mass for an older SF org


#6

janiepuff,

Yes, you can use the migration tool, including destructive changes, as you would anywhere else.


#7

Hi @Jeff_Jobs have you had any success or experience moving the metadata into a src directory? Looks like by default the metadata are stored in the workspace directory, but the repo for my project is set up following conventions used by the Force.com IDE and MavensMate, where metadata are stored inside a src directory and not in the repo’s root directory.


#8

Thanks for the post mchang-r7. When using cloud9 using the src folder, which is a must when working with teams using other IDEs, I find that the key is to have a git strategy that makes sense and then couple it with the force.com migration tool. In this way, you can totally disable cloud9’s syncing and delete their included package.xml (still oddly on api 35).

I always bundle a build.xml file with carefully constructed targets in my git directory so that when I clone it, I have it in cloud9 or any other place I need it. I will also bundle in some bash scripts that make using the migration tool easier. In this way, I can use the migration tool to deploy and compile my code to the Salesforce sandbox of my choice, and also do the same with retrieving existing code from the Salesforce sandbox of my choice.

I’ll typically use the included cli tool in a terminal window to test and debug my code in combination with vim.

In this fashion you can use whatever directory structure you want as long as it is committed to git correctly. Then instead of worrying about where the code is so that cloud9 can sync it, you can simply deploy and retrieve right from your git directory as you would locally. As git is used for teams, then when you push your code and someone else grabs it, it is in the same structure as they would expect.

Hope that was helpful. It is disappointing that cloud9 does not seem interested in solving this fundamental issue with working on teams - which the vast majority of devs do. I have personally brought this to their attention on numerous occasions. Having to hack cloud9 this much makes me a bit wary of it in general, at least at the current time. I think it is designed to connect to an org, grab metadata, do the dev and testing, then push it back up as a single developer working alone. However, many devs need a complete solution that provides more control and a consistent directory structure for their team to share - many team members of whom do not use cloud9. So we have a fundamental design flaw from the outset. It needs to be addressed if this tool is going to have any longevity in the marketplace, imho.

Happy coding!