Integrate CMS Content Into Lightning Communities with CMS Connect
Team Development on Force.com with Github and Ant
1. Team Development on Force.com
with Github and Ant
Tom Patros, Red Argyle, Principal
@tompatros
2. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties
materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results
expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be
deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other
financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any
statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our
operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of
intellectual property and other litigation, risks associated with possible mergers and acquisitions, the immature market in which we
operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new
releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization
and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com,
inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. This documents and others
containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently
available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based
upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-
looking statements.
3. Red Argyle
All About
Force.com development and consulting shop in Upstate
New York. We specialize in custom apps, portal
development, product development and admin support.
Founded by Tom Patros (@tompatros) in 2010
Partnership with Garry Polmateer (@darthgarry) in 2011
Staff in Buffalo, Rochester, Albany and Corning, NY
www.redargyle.com
4. Goals For This Session
Teams
Org Topologies
Source Control Integration
Deployment Approaches
6. Teams : The Lone Ranger
90% custom development. Works in
sandbox (hopefully).Source Control =
Sandbox. Deploys to production (Change
Set / Eclipse).Benefits?
Challenges?
7. Teams : The Dynamic Duo (or Trio)
Custom or product development. Multiple
developers in one sandbox. Source
Control = Sandbox and backups. Deploy
to production (Change Set /
Eclipse).Benefits?
Challenges?
8. Teams : Those Dudes From 300
Custom or product development. Multiple
devs in multiple dev orgs. Source Control
= Git / SVN.Automated deployments
(Ant).
Benefits?
Challenges?
10. Org Topologies
"The collection of SF orgs, their
relationships and purposes to support
Force.com development".
In other words...
Dev Orgs, Sandboxes and Production
11. Team-Driven Org Topologies
1 org. Challenges with scaling beyond one dev.
Overwritten code.
“Refresh from Server” is your new job.
13. Team-Driven Org Topologies
1 org / developer. Developers have the most flexibility.
Source control, deployment management
become important.
14. Project-Driven Org Topologies
1 org. Similar to team-driven scenario. Scale will
become a challenge.
Naming conventions and / or namespaces
become important.
15. Project-Driven Org Topologies
1 org / project. Most-flexible development approach.
Again, naming conventions.
Source control, deployment management
become important.
16. Purpose-Driven Org Topologies
1 org to dev, test and Difficult to know when / how to test.
stage. Client access for review is sketchy.
You can’t deal with issues anywhere else.
Most of us probably work this way.
17. Purpose-Driven Org Topologies
1 org to dev and test, Dev and internal testing happen together.
1 org to stage. Client can be directed to staging.
You can exercise your deployments.
18. Purpose-Driven Org Topologies
1 org to dev, 1 org to Dev and internal testing are isolated.
test, 1 org to stage. Client can be directed to staging.
You can exercise your deployments.
Automation options.
20. Adopting Org Topologies
Decide on the smallest, most helpful change.
Don’t forget about Admins.
I repeat. Do not forget about Admins.
Source control can help.
21. Your Turn
What recent or recurring challenges do you face with team
development on Force.com?
23. “Git is a free and open source distributed version control system
designed to handle everything from small to very large projects
with speed and efficiency.”
http://git-scm.com/about
It’s source control that (mostly) makes sense.
24. “Github helps people build software together.”
http://github.com/about
It’s a Git service provider to manage teams and projects.
25. Git Commands and Clients
Commands tells Git what to do (clone / commit / push / pull / etc)
Clients make those commands easier.
Github App (Win / Mac)
Gitbox (Mac)
Git for Windows (Win)
TortoiseGit (Win)
Try them all out, find the right fit for features and metaphor
28. What Just Happened?
1. Created a Git repository in Github.
2. Push to repository with Force.com IDE files.
3. Permission sets help remove (some) profile requirements.
4. Developers pull from repository, align to their own dev orgs.
5. Configure (profiles, permission sets, etc).
6. Do work.
7. Repeat from Step #2.
31. “Apache Ant is a Java library and command-line tool whose
mission is to drive processes described in build files as targets and
extension points dependent upon each other.”
http://ant.apache.org
Tom says: “it automates stuff.”
33. What Just Happened?
1. Developer pushes to Github repository.
2. Github sends a message to the build server.
3. Build server pulls from the Github repository.
4. Build server deploys to Salesforce org with Migration Tool.
34. Conclusion
There are lots of moving parts (including many we didn’t cover).
There is more than one way to do it.
There is no right answer, but there might be a better answer.
Try multiple dev orgs - it’s a big step but has big potential.
Try source control - it will help bring order to your projects.
Try the migration tool - it’s efficient and can be automated.
35.
36. Resources
Git - http://git-scm.com/about
Github - http://github.com/about
Ant - http://ant.apache.org
Force.com IDE -
http://wiki.developerforce.com/page/Force.com_IDE
Force.com Migration Tool -
http://www.salesforce.com/us/developer/docs/daas/index.htm