In this post, we will look at some of the best practices and patterns which will enable multiple developers to collaborate efficiently on a LightSwitch project. In Visual Studio 2013, there are several new features geared toward enabling team development like partitioned model files, flat project structure, and better integration with Source Code Control providers. Let us look at some of the highlights before diving into best practices.
Partitioned Model Files
In Visual Studio 2013 there is now a separate model file for every entity, screen, query, data source. This dramatically reduces the probability of two developers stepping on each other’s changes and encountering merge conflicts during development -- especially if they’re working on unrelated entities/screens.
.
Flat Project Structure
Getting Changes from a Source Code Control Server (Repository) is easier and the changes propagate correctly to all the client projects, even when the project is open in the Solution explorer. So any changes pulled from the SCC server are immediately visible in the Solution Explorer.
More Support for Version Control Providers
Developers can choose from Team Foundation Server’s version control for on premises (TFS on-premises), in the cloud (TFS online), and Git. All source code control providers supported by Visual Studio can be used for LightSwitch projects.
To use TFS online, you can sign up for up for a free account at http://tfs.visualstudio.com/ . Git is also an option. To start using Git with Visual Studio, I would highly recommend reading Scott Hanselman’s blog post: Git support for Visual Studio - Git, TFS, and VS put into Context
Source Code Control Best Practices
The following are some of the patterns and practices which can help in making team collaboration on LightSwitch projects easier.
- Focus on developing the Data Model and its associated Schema before designing Screens.
- It is a best practice to have developers divide the tasks so that each developer is responsible for a set of Entities, Screens and Queries. For instance, if there are two Entities namely Customers and Products, Developer1 should work on Entity/Screens/Queries for Customers while Developer 2 should focus on Products entity and its associated screens and queries.
- Once the initial data model is ready and checked-in, try to keep subsequent changes as atomic as possible. Incremental and frequent check-ins are preferred over bulk and infrequent check-ins. This practice also helps in resolving manual merge conflicts easily.
- When checking in, it’s necessary to check in all the changes to related model files at once rather than single files at a time. This is necessary to keep the overall model (combination of all the lsml files) consistent.
- Sync to latest changes and sync often. Also sync latest/resolve merge conflicts before checking in changes.
- If you need to roll back any changes, make sure to roll back complete changesets rather than specific files. It’s critical to keep the underlying model consistent and making sure your changes are atomic (sync, roll back, undo, etc.).
Handling Merge Conflicts
Merge conflicts are bound to occur when two developers try to check-in conflicting changes or sync to the server version of the source code control repository while having pending changes locally. There are two possible outcomes for this scenario.
- Auto Resolved: This happens most often when the changes are in different files or the changes involve actions like the addition of files. Developers do not have to manually resolve any conflicts in this case. This is one of the most noticeable impacts of having partitioned model files in Visual Studio 2013. The net result is that both changes get checked in seamlessly.
- Resolved Manually: There will be times when developers make changes to the same files. here are 3 possible ways to resolve the conflicts.
Take Server Version: If this option is selected, all the conflicting local changes are overwritten with the server version.
Keep Local Version: If this option is selected, the local changes are persisted. Note that after this step, the changes still need to be checked in and are listed under "Pending changes". A subsequent check-in operation will replace the conflicting server files with the changes that got checked in.
Manual Merge: By selecting this option, we intend to resolve each conflict by deciding which portions of the server changes to take and which portions of the local changes to retain. A merge tool is provided by Visual Studio to assist in merging the conflicts.
In this example, we would like to select both Entities; namely, User Profile from Server and Gadget from Local workspace. To merge correctly, first check the box to the left of Server. Then at the end, select Gadget from Local workspace. The result gets populated in the result box.
NOTE: There are a few known issues for LightSwitch in Visual Studio 2013 Preview that we're still working on. You can find those in our release notes located here: LightSwitch in Visual Studio 2013 Preview Release Notes
Conclusion
We hope that with the Visual Studio 2013 preview release of LightSwitch, you would find collaboration on LightSwitch projects to be a smooth experience. The best practices and patterns mentioned above will hopefully help you in planning for multiple developers to work productively while collaborating on LightSwitch projects.
We hope you will try out these features by downloading the Visual Studio 2013 preview and let us know your feedback by adding a comment below or visiting the LightSwitch forum.
-Raghuveer Gopalakrishnan, SDET, LightSwitch Team