This is a must. 

There are times where I need to update and upload just one or two files and not upload all of my changed files.  I can and do work on multiple things at the same time, which have different priorities.

Thanks!

John Harcourt

Hi John,

Hi,

Thank you for you suggestion.

We've discussed this variant also. This is one of the several possible ways.

We will work on this way. 

I'm afraid I cannot tell you the exact terms when this feature will be implemented.

Anyway I'll keep you informed about the implementing this functionality.

Regards,

Kate

Yes Please, this is one of my biggest icks.  I get a lot of request to do a quick update to a file while I'm doing other work. I would like to be able to update the issue. deployed it with out having to ether open SF dev console to make the changes and then have to sync back to TWS project or comment out changes till it get a deployed. 

Hi Eric,

Thank you for your post and for your use case.

We have this feature request in our Backlog. Right now the work on this option isn't included to the nearest sprints, however, if a possibility to add this to one of the nearest version of the IDE would appear, we will do this.

Thank you for your sharing your needs related to The Welkin Suite IDE.

Regards,

Kate

+1 it is the biggest stumbling block for me...

The product is better in many other ways but this ability to put on individual files is a must for me.

Hi Jack,

Thank you for your post.

We will implement this for sure, and I will keep you updated when a possibility to update one selected file will be available for you in The Welkin Suite IDE.

Thank you for your interest in TWS.

Regards,

Kate

Not using the product until this is implemented.

Hi pcjones10,

Thank you for sharing your opinion with us.

While we understand that this is a great feature to have an option what exactly to build, you can use the "build" option (or press F5) immediately after doing changes in a file - executing build automatically saves the changes as well. This means, that, if in other tools your changes are sent to the org after saving the file, in TWS for now you can have the same approach (with the same number of actions needed from you) - your changes are saved befor sending to the org.

Please let me know if this approach doesn't work for you, and, if possible, please describe your use-case - we will highly appreciate this.

Thank you,

Vladimir

Vladimir, 

I think the most important part of this feature is time to deploy the changes. It's something that keeps brining me (unwillingly) back to IntelliJ and Illuminated Cloud. I hit save, and my deployment happens MUCH faster than saving via Welkin Suite. Is this something Welkin is looking at? This can be especially cumbersome when making small changes to (for example) static resources. Welkin Suite often asks to pull the file from SFDC and is not detecting the change I made on my local version - Wondering if this is also due to compiling the entire dependancies vs. just pushing the actual file you changed.

Jay

Hi Jay,

Thank you for sharing your experience.

It should take a long time to deploy the changes, so can I please clarify - in case you are deploying the changes for only one file (other than static resource) is it still longer? Can you please let me know how long on average does it take to deploy a single apex class/trigger, for example?

And the same questions for a static resource file - if it's only 1 static resource, is it still longer? How long does it take to deploy it? And what is the size of the static resource?

You can find the duration of the build process (deployment) in the Output panel - it's shown immediately once build starts.

Looking forward hearing back from you, so we can investigate this situation and improve the performance where possible.

Thank you,

Vladimir

I was just about to write a freature request when I saw this post.

One of the few things that I really liked about Eclipse as an IDE for Salesforce was their option to right click within the code screen to pull up a menu where you could click to Deploy that single file to the server.

It looks like the attached image.

The way I think this translates to Welkin is you have a deploy to server button and when you click on it then you get the deploy screen with only the box checked off related to the file you right clicked on with all the other boxes left unchecked.

Now granted compared to Eclipse there is a bit of an issue. You could be deploying a version of the file that is not the most recent if it has not been built yet but that is ok, I think its on the developer to make sure they have built the file.

For lazier developers such as myself this was a real time saving feature with Eclipse especially when your workflow includes worst practices like deploying and testing on production instead of in the Sandbox. Having this feature makes this sort of iteration a lot more convienient.

Hi Joseph,

Thank you for your post with the suggestion.

We already have included adding the save and build options for one file to our development backlog, however, as we understand your idea is a little bit different.

We agree that this would be good to have an ability to deploy one file to another Org also, and we will consider how we add this to TWS. Thank you for bringing this to our attention.

Of course, during the deployment to another Organization, this would be necessary to specify the appropriate credentials, but in a frame of implementing of SFDX functionality, our developers are working on the Credentials Manager. In future versions of The welkin Suite IDE, we are going to add the same functionality for regular Salesforce projects too - so this will save even more time.

Regards,

Kate

Any update on this?  This is a major stumbling block for my team as we all work out of a central repository and pull our code from there into our own individual developer sandboxes.  When we pull from the repository that was recently updated, we are getting consistent compile errors from class dependencies that other developers have committed to our repository.  This would be a huge improvement to our current process of either consistently refreshing our sandboxes or deploying down changes when we run into these issues.

Hi Erik,

Thank you for your question and for your example.

This is present in our plans for the future, however, right now I cannot tell you when exactly we will work on this.

May I please clarify with you if the files that contain compile errors in your case were not built to Salesforce before pushing them to a repository?

Thank you,

Kate

They were indeed built to salesforce before they were pushed to the repo, but they were built in a separate developer sandbox and deployed to production, so when I branch off of our production/master branch, I have their new code trying to build to my developer sandbox when I build my code.  We have a few options for workaround, such as refreshing our developer sandboxes often (as often as once a day), but this can present problems if one developer is working on multiple projects simultaneously and doesn't want to refresh and obliterate their code.  We can also use the Force.com Migration tool to pull a temporary package, refresh our sandbox, and then deploy the code back.  Still not ideal, but a feasible workaround for the time being.

Hi Erik,

Thank you for providing additional details on the flow that you're using.

In the regular Salesforce projects (not SFDX ones) I'd not recommend applying the "partial-deployment" approach - in this way you won't be able to benefit from multiple helpful features in the IDE that "expect" your code to be as precise copy of your dev environment as possible, just to name a few:

• Debugging your code with our Retrospective Debugger might work incorrectly or not work at all, if the local code is significantly different from what you have in the Org
• Code coverage details also won't (or might not be) very helpful in this case, especially the Code Coverage Highlighting
• "Go to source" from your debug logs files also might not work properly
• List of unit tests in the "Run tests" wizard will show you the list of tests based on your local code, rather than on the Org's codebase

Anyway I want to stress that we have the option to build a single file from the IDE :)

Knowing how slow might be refreshing sandboxes I even won't propose you such option, as doing it on a regular basis will waste so much time.

What do you think about the following option - when you're pulling the code from the repository I guess that you're resolving all conflicts, so after the pull you should have everything that you need in the local repository. Instead of doing a temporary package and refreshing a sandbox - won't it work for you if you can just "force deploy" everything from your repository to your sandbox using, for example, Salesforce Migration Tool? If this should work for you - you can add a .bat script file as well as the ant task to your repository and call it very quickly from the IDE, using the Tools -> External Tools configuration option.

What do you think about this? Or if this won't work for you we can try to think together and find a good/better workaround for you.

Thank you,

Vladimir

Not a bad suggestion, Vladimir.  Unfortunately, our repository (for now) is only a repo for our Developer metadata (Apex Classes, Triggers, Visualforce Pages, Components, and Aura Bundles), so when there are dpendencies on the more declarative metadata (such as Objects, fields, custom settings, etc.) a force deploy would still fail.  I definitely think you're suggestion with some Force.com Migration Tool automation on a pull from the repo (getting more into a Continuous Integration solution) is the way we should go. 

 
One of our drawbacks, currenlty, is that we already had a repo in place prior to the purchase of The Welkin Suite. Our repo's folder structure is different from The Welkin Suite's folder structure, in that it actually is a match of everything below the 'src' folder whereas The Welkin Suite includes the 'src' folder in it's repo structure.  As a result, we have been doing all of our git commands either in an external git tool like SourceTree or directly in a bash terminal.  This could likely be easily changed and all of our local repositories can be made to match (adding everything to a folder is a simple git task, really).  With that being said, as I am not seeing External Tools as an option under Tools, is that an option that only appears when version control is enabled, or is it only a Windows option (most of our developers are Mac users, including myself).

Also, when you say that you have the option to build one file at a time, is that feature included on the Blaze R6 release, or is it a Bloom feature?

All of this will likely become less of a problem when we move over to Salesforce DX.  We have already enabled our production org as a Dev Hub org and will be moving to a DX scratch org style of development once we are able to put in the time to segment our Salesforce instance into smaller "Products/Artifacts" with their own repos.

Thank you so much for taking the time to discuss this with me.  You guys are killing it with continually releasing awesome features!  The responsiveness to these issues/concerns is also really refreshing, have received none of this level of support and care, even from Salesforce themselves.  So keep on rocking it!

Scratch that on the External Tools question.  I reviewed your documentation on this or Mac users, and I see where in preferences I can setup these External Tools.

Hi Erik,

Looks like your case is pretty complex - this why I'm so happy with SalesforceDX so our teams can start using Git without any overhead and complex workflows or issues :)

First of all - yup, SalesforceDX might be a great solution for your team, however if your project is nig enough you should accordingly allocate "enough" (meaning "pretty much") time to convert it to the SFDX one, especially if you'd like to make it cool and right with smaller artifacts :) While SFDX is two levels higher (at this state) than many other SF features for developers, it's still not ideal, so time is needed to fight it's childhood problems...

And talking about the non-SFDX approach it seems to me that the best case wouold be to also invest some time to reorganize Git repo & maybe your workflow. I can't suggest you doing this, but this is what I think might be a good approach, that won't take more than 1 day for the team to switch over (maybe +1 day to add additional CI configurations):

• Change the repo structure to include TWS's project folder as the root, so there'll be "src" folder inside the repo as well as some other folders
• It also makes sense to include additional metadatas to the repository. For this case I've done a bat script with Ant task that downloaded all other metadatas (that are not supported by TWS) into the src folder. I've played a bit with package.xml file so it won't overlap with supported metadatas.
• In this case everything that's needed to replicate the full state of org will be in the repo, so dev will be able to pull, execute an Ant task to deploy everything to his sandbox and start working with the properly configured sandbox

Another approach is a bit different and the main idea of it is something like "separating repository from the TWS project". As regular TWS project is tied up directly to the org and repository, in general, doesn't case about the org - there might be issues with mixing everything together. Not 100%, but they might be. In somecases it worked very well to do the following:

• Keep the repo structure in the way how it's organized now for you
• Add another metadata types to the repository as well as 2 ant tasks to retrieve everything from the org and to deploy everything to the org
• If you want more automation - make 2 bat scripts to "pull from git & deploy to the org" and "retrieve from org & commit to the Git"
• Devs create separate projects in TWS, which are not linked to the repository in any way and work with them

With such flow the workflow looks like - pull from git & deploy everything to your actual sandbox with ant, open TWS project for this sandbox and pull changes (only for files that are included into the project and that are needed for development), develop whatever is needed and deploy to the org, retrieve everything from the sandbox into the repository folder using ant, commit your changes.

It adds overhead, but from our experience - in Salesforce devs rarely pull from git / commit to git more often than once a day, so adding 10 minutes for all of this actions won't hurt too much.

Otherwise, if not including all metadatas to the git repository - the team will need to manage both git repository & changesets (or refresh sandboxes) to merge changes. From our experience managing state of the development environment with 2 tools at the same time adds to much chaos and complexity :)

Again - maybe this can add some ideas for you :)

Regarding the option to build one file - please sorry for the miscommunication. It's not yet there, but it's in our backlog, so we will definately implement it sooner or later :)

Thank you,

Vladimir

+1 for this feature request. 

This is a MUST have feature in TWS. Imagine me making changes to multiple files to implement a feature and someone asking me to make changes in some other file and deploy it quickly so that they can use the changes in their development. Now with TWS, either I deploy all the changes (previous ones that I was working on as well as the newly requested change) or I have to discard all my other changes to deploy this to SF or I have to use some other IDE/Developer console to make the changes.

This is not at all developer friendly and such a scenario will occur any day. I am not sure why this feature has not been implemented yet. Have been using TWS for few days only and this one thing is already bothering me.

Not recommending TWS to my other team mates for now.

Hi Swagat,

Thank you for your feedback.

We are already considering implementing this feature in one of the next releases.

For the time being you can use the 'Deploy to Organization' functionality (available in the context menu of the project) to deploy only certain file(s) to the same organization that is tied up to your project.

We will keep you updated once this feature request is released.

Thank you,
Vladimir

Got it. Please keep us posted on the release since this is a really important feature to have.

Any update on this?

Hi Brent,

Thank you for your question.

We have added the work on this functionality to our winter plans, so you will be able to use it already in one of the nearest version of The Welkin Suite IDE.

I will keep you updated when this will be implemented in the IDE.

Best Regards,

Kate

This is huge for me also.  Sometimes my projects contain many files.  If I am working out issues in one last file or need to make a last minute change to accommodate an additional request, I only want to change the one file and be able to build it by itself.  After working with other tools that allow this, it seems odd to me that yours doesn't allow the build of one file.

Hi Joan,

Thank you for your post.

We are doing our best to find the most proper way to implement this ability into The Welkin Suite IDE as soon as possible.

I will keep you updated when you will be able to build/deploy one file in TWS.

Currently, as a workaround, you can use the Deploy to another org functionality and update your separate file(s) on the same organization.

Best Regards,

Kate

This was stated to be in the "winter plans".  What is the time line for delivering this feature?

Hi,

Thank you for your post.

There were some changes in our road-map and this is why we have moved the work on this functionality.

You will able to save, build, or deploy of a separate file already in one of the upcoming versions of the IDE.

I will let you know when we will release this feature.

Regards,

Kate

I waste so much time making small changes and deploying them through the wizard. 

Existing flow:

1. Make a change and save component
2. Navigate to PROJECT > Deploy to Organization (Sometimes I accidently go to BUILD > Deploy Objects)
3. Wizard opens
4. Click Next on first "Deploy to Organization" screen (Why is this even a mandatory step every time I need to deploy?  There have been 0 instances where I need to change this while working on a project.)
5. Find the component I've just updated (I have a few feelings about the window...)
   
   1. Window Expansion: 4 columns before the name of the components? wtf yo? I have to expand this window every time I deploy something so I can verify I'm selecting the correct component. Make it wider by default, please.  If I have to go through the current process of deploying, I can't click on anything outside of the window, you don't have to be stingy with space.  It's like being forced to look through a tiny peep hole to do one of the most basic elements of developement: Pushing your code somewhere it can be used.
      
   2. Customization: I can move the columns around, filter values for each column, and run a deep comparison all in this one window. Important features when deploying a large number of components, but all I need is for the Name column to stay put and not go running back to it's original location the next time I deploy. (Nothing more frustrating than setting something down, leaving, returning, and it be somewhere else than where you expect it to be)
      
   3. Sort Order: I just saved a component I've made a few updates to.  I run through the previous steps only to have to search for the component I've been working on. (If I'm lucky, the component name is short enough for me to not have to expand the window to see if it's the Controller or the Test Class I'm looking at).  I want to see the components listed by last modified date.  I know that may not work for everyone, but at least give me some settings I can control this behavior with myself.
      
6. Decide on deployment options, every. damn. time. I should have some defaults that are only displayed if I need them (i.e. As an expandable "Deployment Options" button within a 1 screen deployment confirmation prompt)
7. Click "Next" to deploy. All of the other wizard pages also say "Next" as the option to move forward to a new page. I didn't expect it to deploy the first time I clicked this. It would be nice to know that I'm actually about to deploy.  Suggestion: Name the button that deploys to an organization "Deploy".
   
8. Click Finish. It's great to know that your deployment has finished, but I have to click another button to get back to what I was doing.  If there are failures, keep me in the "wizard" to view the errors, but if my code was fine (as I always assume it is :-P) I don't need to "verify" that I understand this by clicking another button. Exit the wizard automatically and show some sort of banner alert that it was successful.
   
9. Start working again.

If you've read this far, congrats! You've made it through one deployment cycle.  Something I do countless times a day. I find myself sometimes resorting back to Dev Console when trying to debug a problem, because it's faster than the prescriptedly long journey through the Welkin Suite deployment process.  Why are there so many steps between me and what I want to do?  How much time do I waste going through this multiple times a day? I don't know, it depresses me to think about.  

You already have a "Pull from Salesforce" button I can use on discrete components. Is it unreasonable to have the same simplicity in deploying a component back to Salesforce?  MavensMate made it even more simple by automatically deploying when you saved the component.  All I'm asking for is simple option to deploy one or more components.

The bright future I look forward to in a simple deployment using Welkin Suite

1. Make a change and save a component
2. Right click and choose > Deploy to Salesforce
3. Get back to what I'm working on

Just looking at the difference in the number of steps, my deployment productivity just increased by 3x!!!  Woooahhhh! Impressive.  My company is happy I'm able to complete more (i.e. $$$) and I'm thrilled I don't have to rush through repetitive menu options, accidently taking an occasional turns down "Build > Deploy Objects". (I have cut down on this wrong turn by adding a custom "Deploy" button to my toolbar. So many ways to customize and place functionality where you want it to be!  But wait.... there's more! They stay put...)

</rant>

I don't usually get into a ranty internet mood, but it's Saturday and I've successfully distracted myself here instead of finishing the development work I told myself I was going to get done today... So, I'm going to convince myself that writing all of this was worth it and I'll someday see my dreams for a simpler Welkin Suite deployment come true... Good day.

Epilogue:

In case you're now under the impression I hate your product, this is not true.  I really like what you've built.  It works well for the work I do and while it pained me to move to paying for an IDE, I'm glad I did.  It was the right choice for me.  Thanks for your continued work on the product.  You're doing great.  Keep that shit up.

Thanks,

Rob

Rob,

I can feel you man!!

+1 for whatever you wrote. And trust me, I read it all because I also go through the same things.

Let's hope Vladimir gets this in the product soon.

Hi guys!

Rob, thank you for your great and detailed post.

We appreciate your time that you spent to describe your whole flow and issues that you are faced with working on deploying your changes in The Welkin Suite IDE.

We have added several tickets for improvements in a frame of this deployment process, and will work on them soon, so our hope is to get your dream a bit closer to reality. Thank you for sharing your feelings about the wizard with us and for bringing this to our attention.

Also if you do not mind, I would like to just share with you how and what for we intended for these features to work, and maybe this knowledge might help you work a bit more comfortable and smoothly with them.

The ‘Deployment to Organization’ feature is intended for deploying/moving files from your current TWS project to another organization, and this is why it includes all of its present settings you were talking about. This is also why at the first step we have that area where you can enter the credentials of another org and this reasoning is also why this is a mandatory stage. The ability to deploy to the same organization here was implemented a bit after this feature first came to life, as a way to have an additional option to use extended settings of this feature when deploying to the same organization.

Also if you don’t mind, I would like to draw your attention to if you need to just update your files on the same organization, you always can use the ‘Deploy objects’ functionality, and this doesn’t require so many additional actions - this feature is implemented specifically for updating your files as you described: make a change, deploy it, and get back to your working process. In this case, the IDE gathers all the changed files (in a frame of the metadata types that could be deployed, not built) and sends them to your org all at once.

Of course, if you use the deploy to organization, as a workaround, to update one file and not to include all the changed files to this process - currently this is a one way to do this.

I would like to let you know that you can be sure that ability to deploy one separate changed file when there are several/a lot of changed ones, will be available in the IDE in one of the next versions - we are sure you will like this. However currently using the deploy to organization as a workaround to update one file and not to include all the changed files to this process is one way to do this.

Also, we are going to consider your suggestions related to quick access for the Deploy button in TWS UI, and I believe we will make it ‘closer’ the same as the Pull button.

Thank you one more time for your post and for your feedback about The Welkin Suite. We are happy to hear that you enjoy the IDE and will be glad to make it better and more convenient.

Have a nice day!

Best Regards,

Kate

Hey guys, any update on this. IntelliJ, Eclipse, mavens, etc you can just Save and it will push to org avoiding all the long process of deployment. 

ctrl + s or cmd + s and save push. Isnt that much more confortable and simplier that the whole deploy process?

Hi guys,

We hope you are doing well.

I want to let you know that we have started our work on this required functionality and the first summer release of the IDE will provide you with an ability to save, build, and deploy one selected file.

Best Regards,

Kate and the whole The Welkin Suite team :)

Hi everyone!

I promised to keep you updated on our progress on the implementation the requested features for the build process, and you can find the highlights of these upcoming changes here.

Already the next week you will be able to use all mentioned options in the IDE!

Kindest Regards,

Kate

Hi everyone!

We will have a great webinar about our largest release 26 July 9am PDT/12pm EDT/5pm EST. Have you thought what it would be like to have all the metadata from your org in your The Welkin Suite project, but still be able to work with the ones that you most commonly use in the fastest possible way?

Topics of the webinar: Metadata support, metadata sets, Workflow with Git repository, deploy on save, etc.

Save your spot!

Have a great weekend!

Hi all!)

I'm sure that some of you already knows but I want to confirm that we have implemented the save, build, and deploy option which we discussed in the current topic. All of this is available for you in The Welkin Suite Bloom R19 and The Welkin Suite Blaze R13.

You can find more information about all new abilities for your development process here (TWS for Windows) and here (TWS for Mac).

I hope you found them useful and we made your working process more convenient, and. of course, we are going to work on this in future versions of The Welkin Suite IDE.

I'll close the current topic as implemented, however, you can always contact us when you have questions or suggestions!

Kindest Regards,

Kate