I need guidance regarding the Development Life Cycle of using GIT in salesforce.
How to test the latest code that I fetch from the GIT to eclipse. ??
What i’m upto this, is that, after syncing the code from GIT to eclipse we will push the code to the registered salesforce server (sandbox/any other) and will make changes there, and then re-fetch the code back to eclipse from salesforce server (sandbox/any other). And then push it to the GIT.
For this we need a separate sandbox too and separate logins for each Developer.
Please correct me if there is anything improper, or if there is another best way for this life cycle.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
The “full package” of Salesforce development should include the following features:
Continuous Integration
To ease migration, consider a CI solution. This allows developers to stage/unstage code with just a few clicks, or even by automated processes when certain events occur. This keeps the various orgs in sync with each other.
Code Version Systems
To prevent mishaps, using a CVS such as git or svn is recommended. Along with CI, this presents the very real reality of simply having source-driven development, which is much more reliable than traditional org-driven development.
Developer Sandboxes
To prevent yet more mishaps, each developer should certainly be in their own Developer Sandbox. Along with CVS, this helps prevent cases where multiple developers accidentally clobber each other’s work. Also, each developer can choose to deploy only a subset of items to reduce deployment and retrieval times.
QA/UAT Sandboxes
Quality Assurance needs a stable environment to test changes, and User Acceptance Testing makes sure that the users understand the new features and changes. Ideally, this should be two separate sandboxes, with at least UAT having a full set of data from production so users can experience what the system will behave like after deploying to production.
Development Methodology
A well laid-out plan helps get code out the door faster, so adopting an Agile, Scrum, or other similar methodology may help reduce bugs, bring new features to production faster, and provide better documentation than commenting alone. Software such as Trillo, Rally, JIRA, and others can help keep everyone, including developers, QA, BA, and others on task.
So, in order to answer your question, you’ve got part of the design already laid out, but you need more. A QA/UAT environment is for testing purposes, and should be a separate sandbox from all other sandboxes. This is the piece you were probably missing. CI is handy (and strongly recommended), but not required if you’re not at that level of sophistication yet, which is admittedly hard to achieve with current solutions. Some sort of development methodology should also be included in a sound development strategy.
(#SafeHarbor) Salesforce DX helps bridge the gap to a true modern development life cycle by adding smarter deployments, an updated IDE, painless CI with Heroku Pipelines/Flows, and CVS support via GitHub, plus new tools to encourage fresher sandboxes (those that don’t grow stale with old code), along with the ability to swap out the IDE, CI, CVS, and org types as desired. DX isn’t quite out the door yet, but it should provide about 80% of what you need to improve your development cycle (the rest being a development methodology, which you provide yourself). (/#SafeHarbor)
In the meantime, you can look up such CI tools as Jenkins, as well as your choice of CVS, of which several combinations have been documented on official blogs and unofficial blogs. If you’re starting from ground zero, expect two to four weeks of effort to get fully set up, and another couple of months to get well-adjusted to the cycle (we’re just now about there, and we still don’t have CI yet).
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0