Hot answers tagged

28

There are a couple issues with how you're using git, let me talk about each. The problem First, you're treating your Salesforce server as the truth, instead of git. By doing a Refresh from Server each time before you're starting to code, you are updating your working directory with whatever has changed in Salesforce. This will be reflected as a change ...


19

I started down a similar path about 9 month ago when I started at the Salesforce.com Foundation and was tasked with building the continuous integration architecture for the next major version of the Nonprofit Starter Pack. We're now at the release phase of the development process and have confronted a lot of the questions you pose. Before diving in on the ...


12

The two answers @Jagular referenced are good and @JonathanHersh is right about git just being a tool. Most of what I'm saying below isn't git specific, though. The same could be said about SVN, CVS, etc. Here are some pain points, assuming a setup where each dev has their own org (e.g. developer edition). They can be dealt with, but are good to be aware of ...


10

I cannot answer the Git related parts, since we are using BitBucket with Mercurial, but i can give some insight to question 2, 3 and 7. Are you using seperate repositories or branches for Patches / patch orgs? We are opening a new branch for each patch. The branch starts at the commit, which marks the release. Older patch branches are closed over time, ...


10

Disclaimer: I work for Gearset. You could use Gearset (http://gearset.com) - we built it for exactly this purpose! We do several things around tracking and migrating changes between orgs that might help in this scenario: Daily scheduled comparisons to show org changes over time (great for auditing changes that have happened to an org since you last "...


8

The accepted answer for this question discusses using Git with multiple developers: How to use GIT on multi dev environment The accepted answer for this question talks about managing Git with Sublime Managing Git with Sublime Text Salesforce IDE plugin (HaoIDE)


8

Since you've already cloned the repository, you can proceed as follows. Click on File > Import > Git / Projects from Git > Existing Local Repository > Add... (add your repo's local directory) > Import as General Project > Type a project name > Finish. Then, right-click on the project, choose Force.com > Add Force.com nature. After that, right-click on the ...


8

Do we need to work each developer in a different dev environment? if not, is there any way to work in the same environment without step on each other's toes? When developers work in the same org, they tend to overwrite each other's work. You can avoid this with frequent communication and setting up some safeguards in each IDE (like checking the modified ...


7

meta.xml files for code carries two important attributes 1)An attribute for mentioning version 2)Status of your class Ideally it is better to checkout both to SVN so that in case one of your dev change status of the class or version ,its tracked as well. Also very important point to note is without meta.xml file you won't be able to deploy code to PROD ...


7

Salesforce DX is the future of source-code-driven development. Instead of spinning up Developer Orgs that you have to clean up, or Developer Sandboxes that take hours to populate, DX creates new sandboxes in a matter of seconds, can push a decent-sized code base in a few minutes, and can even script data loads for you, with relational data across many ...


7

This answer is relevant to Salesforce metadata and also to anyone dealing with large blocks of XML or similar repetitive text. When working with large files in version control, especially large XML files like you get when working with Salesforce, the default behavior of git is sometimes not ideal. When one block of XML is removed and another one inserted, ...


7

Read the answers on What's the best practice for putting multiple projects in a git repository? for some possible solutions (over on Stack Overflow). My biggest concern is that if you end up screwing up something in one of the projects, and you try to fix it, you might end up reversing changes in other projects by accident. If you do decide to follow the ...


6

The best practice we've settled around is that developers don't connect Eclipse to a packaging or patch org. Instead, all coding is done in the developer's own DE org, committed to a branch in GitHub, and then deployed to the patch/packaging org by Jenkins (or any other automation tool of your choice). The packaging and patch orgs are only changed by an ...


6

There are a bunch of third party solutions offering native CI for Salesforce. Full disclosure that I lead one of the companies building one but I'll provide you with all options so you can investigate. Gearset - 30 day trial and no org install so easy to start with. Copado AutoRabit Flosum SalesforceDX will also bring standardised tooling to make ...


6

I'm not an employee of this vendor, but you can use Gearset to easily deploy from both BitBucket, GitLab and GitHub to any SFDC org (and you can deploy from a feature org or scratch org to BitBucket, GitLab or GitHub). Gearset offers CI job support - everything through point-and-click tools. Cost is reasonable, especially considering the value provided.


5

I've used Subversion (SVN) and Git on Force.com projects. Either will work, but click around in the cool Github UI for a few minutes e.g. https://github.com/forcedotcom/aura (this is some of Salesforce's open source) and I suggest you won't want to use anything else. Follow the links in Jenny B's answer for the various other points of comparison or Google ...


5

I'm also a consultant. We don't see a need to mess with the Ant tool or any of that nonsense. We utilize MavensMate and Sublime Text 3 along with the sourceTree or the git client of your choice. MavensMate handles the local <--> sfdc connection and git takes care of the rest. If you're not set on a fancy gui for git you can even do everything inside ...


5

Manually moving is not scalable and there will be additional challenges like everytime your external developer org needs to sync the changes you do to your sandbox organisation . The scalable and long term solution would be to set up a continuous Integration Process (CI) along with git worlflow to manage the Code merging . There are lot of open source ...


5

That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do ...


5

First, as I said before, don't merge directly in to master. Also, don't do crazy diffs and stuff to try and make it work this way. You're right to be concerned about automatic package.xml generation, it's a non-trivial task at best. I recommend reading A successful Git branching model (not my blog/post, just really useful!) for a better branching strategy. ...


4

I've been building an installer for the Salesforce.com Foundation's upcoming release of NPSP 3.0 which can effectively handle installation/upgrade of dependent managed packages as well as bundles of metadata in a zip file (via a url). This definitely has made it a lot easier to deploy dependent managed packages along with unpackaged code which doesn't play ...


4

I can provide a more specific answer from the CumulusCI perspective. First off, the webinar you linked to is quite old. Here's some better reference materials: Dreamforce 14 Session Videos: Automating the Impossible Reusable Build Scripts for Managed Package Development Other Resources Nonprofit Starter Pack Contributor Docs Diagram from Automating the ...


4

With the advent of 2nd Generation Packaging and Developer Controller Packages with SalesforceDX; Salesforce is telling us to break a project into related components called artifacts. These artifacts/DCP's can be stored, versioned and released independently. To answer your question, let's take an example : All the source-code for project 1 resides in ...


4

The problem is line endings. Windows uses CR;LF, while *nix uses LF. Obviously, Win line endings use more space. So the solution is to change all line endings to the *nix one (LF). I'd actually recommend always use *nix line endings, as they generally produce less problems. To change your git config to use LFs do: git config --global core.eol lf git ...


4

I'm not really sure how your repo got into this state, but you have two remotes (server repos to which you can push changes from your repo) configured, and one of them (upstream) has the wrong URL. You don't need two remotes here because they're actually both pointing at the same repo, your bdJohnson72/GloboHealth repo on GitHub. I would fix origin by ...


3

Disclaimer: I work for Gearset. I can't speak directly about CumulusCI, but I can talk about some of our experiences over the past 12 months talking to Salesforce developers and admins all over the world about their existing deployment / CI processes. With respect to your specific questions: I think in an ideal world, configuration changes should be ...


3

If your production changes are all checked into your git master branch (assuming this is the branch representing production) you can merge the production changes into the other working branches and those changes can then be pushed to the orgs just like any other modification to the source would be. This really isn't any different than a patch or a breakfix ...


3

You could accomplish this with ant and the Metadata Toolkit. Install Apache Ant. Install Metadata Toolkit into Ant. Install git. Configure git. Create build.properties, build.xml, and package.xml. Pull initial set of classes, components, etc using sf:retrieve. Commit initial repo for git. At this point, you've got a working baseline. Ant can manage all of ...


3

Bottom line is cleaning DE orgs is problematic at best. You do need to list all of your components in the destructiveChanges.xml file unfortunately. The platform will not implicitly delete references nor let you ignore them. There are also some bugs / features even if you do reference all the components. The solution we have found is to develop a 'dynamic'...


3

Upon further research, I believe this occurs when Eclipse does not shut down properly, due to either a crash or a force close. While eclipse is running, it creates snapshots of the workspace changes incrementally, on a regular shutdown, the workspace is saved and the snap files are deleted. When a crash occurs and the workspace isn’t saved properly, on ...


Only top voted, non community-wiki answers of a minimum length are eligible