The modern Salesforce development workflow with Visual Studio Code
June 29, 2015
- JsForce, nForce, ngForce, Heroku Force, etc…
- Control Salesforce from any environment: Command Line, Server, Browser
- Heroku + Heroku Connect for NodeJS / MEAN Salesforce apps
- Electron Engine underpinning Atom & Visual Studio Code
What is Visual Studio Code and how does it fit into this picture?
VSCode is an incredible NodeJs development environment. It provides native NodeJs debugging, something that no other free editor provides. It’s even built on Node. It uses the electron shell, which interfaces with Node and the V8 engine, but uses Microsoft’s Monaco code editor.
So get to the workflow already
The Platform: It all starts with Node
- NPM, Bower, JSPM can all be used to retrieve packages. Most things can be found with NPM. JSPM is an interesting new alternative.
Source Control and Project Management: Keep everyone up to date
SVN, Mercurial, or Git: Use Git
When working in a team, proper branch management is a key part of your workflow and special attention should be paid to making the process of branching and merging is as painless as possible.
Use “GitFlow” as your branching and release management strategy: utilizing separate feature, develop, release, hotfix, and master branches, keeping broken code out of master as much as possible.
Bitbucket or Github: We like Github because of it’s simple interface and better integration with other tools, such as Slack.
The differences between the two products is mostly aesthetics, with Github costing a bit more
The combined offering from Atlassian of Bitbucket, Jira, and Jenkins is compelling works better for some enterprises
Jira, Sprintly, or Zenhub: Mostly a case of personal preference by your project manager, we like Zenhub because of it’s dead simple interface and tight integration with Github.
Code Generators and CSS pre-processors: Don’t Repeat Yourself
- Yeoman or Slush: we like Slush
- Stylus, Less, or Sass: we like Sass
Generally, use the tool that has the content you want. Each has their benefits, but they’re not really important when just starting out.
The Build system: The Magic
- Grunt is a task runner. It’s a common tool that is most often misused as a build system. Don’t fall into the trap, since it’s a task runner it accomplishes things through reading, transforming, and writing files. When things go wrong, it can get messy.
- Gulp is a streaming build system. It transforms source code through a pipeline. It works great as a modern build system with RequireJS, but it has it’s limitations.
Webpack is what is next. It uses CommonJS syntax, so you can assemble your client app like your server app.
- It can import, assemble, bundle, uglify, and minify your code. And will give you a map!
- It can optimize, transform, preprocess, and assemble all your front end assets.
- It can run all your functional and integration tests
- It can even watch every one of your files and do all of that automatically, any time you save any file it cares about. It can even deploy all of that code up to Salesforce, automatically, about as fast as you can Alt+tab. Let me show you.
Demo of Webpack-Salesforce-Auto-Build-Deploy
Continuous Integration and Deployment
- Jenkins, CumulusCI, and CircleCI: CircleCI works great with Github
- They can deploy to whatever organization you want.
Finally… Other Tools
- Use Slack for integrated team communication. Integrates well with Git and CircleCI, and many other tools
- GoToMeeting for important internet meetings,
- Gmail and Hangouts for company wide and person to person communication.
The final word
We’re Agile at CodeScience
The process of development starts before the first bit of code is ever written. Software development is a complicated process that involves merging abstract concepts contained in the individual minds of team members into a structure that provides value to everyone. Because of this complexity, software development is a time consuming and expensive process. In order to minimize waste, we need to pay special attention to reducing effort and development time during our build process.
It’s virtually impossible to build the right thing the first time. There will inevitably be incorrect assumptions and miscommunications. To build software properly, we need to have good tools that allow us the flexibility to change our code quickly and easily. We need to be able to properly debug an application.
What is Modern?
Design Before development can start
We have to first understand what we’re trying to build before we start building it. We do this through first establishing user personas. We have to know who we’re going to be building the application for in order to know what those users will need the application to do.
Establish the personas that will targeted with the MVP.
Proceed to build scenarios or use cases for each of the personas involved. We do this so we can establish what the basic requirements are so each persona involved can derive value from the application.
We then proceed to wire-framing where the UX designer creates an initial walk-through of the application. This allows the team to review a concrete idea to find where the issues are with the design. We do this so we can figure out how our assumptions are wrong sooner. It allows the team and product owner to review each aspect of the MVP and create a dialog about what features are missing or possible different ways to accomplish a certain task.
The modern workflow starts with development mockups in Lucid Charts or another wire-frame tool that can be easily shared amongst the team.
Telling Agile Stories
After we have a good idea about the structure of the application and the needs of the users, we start writing User Stories. These short sentences, best captured on a Sticky Note, provide tidbits of functionality that will provide some business value. We structure our use stories to the business value is always included.
A good practice is to write these user stories directly into Github as issues. These issues provide our backlog. We can use Zenhub to organize our backlog into pipelines, sprints, etc…
After we have a collection of user stories that can account for our personas walkthroughs, we begin to groom them, or add acceptance criteria to establish what a tester could do to prove that the user story is satisfied and the business value can be utilized.
We then need to size the stories so we can properly do Sprint Planning. We use story points to size each story based on it’s estimated time, complexity, effort, etc… basically how long might it take to complete.
Then product owner prioritizes the backlog to give an order of what business functionality is most important. We do this so the team knows which items to pull into the sprint backlog first.
The Sprint backlog is built and the Sprint can begin
Once the team has established what features will be delivered during the first spring, the can begin the process of actually implementing the tasks that are requested.
All of the previous steps could all be done using Lucid Charts, Github, and Zenhub. Communication amongst the team and with build tools can be consolidated with Slack.
TDD and BDD
Once we have the user stories and acceptance criteria, we can establish what tests we will need to run. These tests should be unit tests, or test a well factored bit of functionality, that should align with the acceptance criteria of the user story.
Implement the functionality
Now that we know what we need to build and we can test that it’s not built yet, we can start to actually build the code that will drive business value. It’s may seem strange or wasteful to the client that nothing has actually been built until now, but as development is the most expensive and unpredictable part of the process, we need to reduce the risk of wasted time by building the wrong thing.