Sharing Project Files

The Welkin Suite Forum

Sharing Project Files



Sharing Project Files

  • Please log in to reply

#1
windows version welkinsuite

lryan

    Posted 18 May 2017

    I am not understanding something basic about managing projects.

    I have been working on a project for about two months.  Another developer is joining the team.  He installed TWS and got all my project files from our Git repository.  Then he opened the project in TWS.

    We changed the project properties to point to his Sandbox instead of mine.  So I guess each developer must have their own version of the project file, is this correct?

    Anyway he built the solution, which I thought would upload all the files to his Sandbox, but it did not.  I could not find anyway to upload the files to his sandbox.  I guess I could try deploying from my TWS to his org.  But then what happens when we start changing files and pulling the changes from GIT?

    I am really struggling to understand how two developers working in two separate sandboxes work on the same project.  Can someone help?

    Thanks,

    Lisa


    Following up on this:  we've been working on this for a whole day now and no closer to an answer.

    My new developer developed a VF component and committed it to our Git Repository.  Then I pulled it using SourceTree.  Now the component files are in my local repository.  But I cannot figure out how to get them into my project so that I can push them to my Sandbox.

    Can someone please explain how we are supposed to do this?



    1 replies to this topic

    #2

    kate.dulko

      Posted 19 May 2017

      Hi Lisa,

      Thank you for contacting us with this question.


      The project which you are working with in the IDE is related to one separate Organization - reconnecting the same project to different sandboxes by different developers will cause issues with building changes, because of the following reasons:
           - we are using hashsum (both local and remote) in order to detect what files should be sent to the Organization during the build process, and some hashum data is stored in the .sfproj file, so it will be very complex to manage changes in the given way;
           - we are also using the information about the last modified date&time for files on an Org to detect if they need to be sent to it during the Build.


      In the case when you need to replicate one sandbox to another we suggest using 'Deploy to another org' functionality to update files on another sandbox.

      After another sandbox is created another project can (and, ideally should) be created to work with it without any interference with the initial project.


      In the case of adding Git version control to this workflow - it adds a lot of complexity on your side for merging changes as working with any version control in your team with Salesforce is very complicated (due to the fact that Salesforce itself may be treated as some kind of remote repository). We are not able to advise you what exactly Git workflow to use, however a pretty common scenario that we see and hear from our customers is to use different branches for different organizations and perform branch merges when needed.

      In this case, you can also use 'Deploy to another org' functionality or Ant migration tool to migrate some of the changes between sandboxes or sandboxes and "staging/rc/qa" environments.


      Thank you,

      Kate


      Kate Dulko
      Customer Relations

      The Welkin Suite

      twitter: @KateDulko
      skype id: d_katerina
      e-mail: kate.dulko@welkinsuite.com

       

        





      Boost Your Productivity. Get Started Today

      Try Free Trial