tl;dr: I need a development workflow for ASP.NET apps that works for the designer on a Mac, the content writers who don’t have visual studio, and the C#/.NET developers (mostly me), such that we can have Continuous Integration and normal branching and merging.
Current workflow
A designer and a few content editors make tweaks to the site on our development/staging server (mostly HTML and CSS changes, plus occasional tweaks to some JSON files that define content). Once they like it, they ask my boss or me to commit and push those changes. The staging server actually hosts a cloned copy of our site’s Git repository. We (my boss or I) connect to the clone and commit using git (SourceTree, actually), and push the change, which causes it to deploy through continuous integration.
Why This Sucks
- It looks like my boss and I are the only ones committing.
- If someone’s SourceTree app is touching the repository on the dev site at the same time as you, it can prevent you from committing.
- The development environment is substantively different in how it’s deployed from the production environment. This effectively creates “builds on my machine” scenarios even though we’re developing against a server.
- We can’t use pull requests and code review, which are really helpful when a less-technical person is submitting code.
- We’re working with one branch, so it’s easy for the production source to get polluted with commits that are unstable in the production environment. That makes reverting dodgier.
Where to go next
I would much rather have a workflow where people clone the repository, create their own branch, make changes and commit them, and then do a pull request (or just merge) into the develop branch, and let the CI server do the deployment routine in the development environment first.
There’s a couple issues with this:
- Most of the people making changes need the instant feedback of editing files on a live webserver. We could have them build/run the apps on their machine, but…
- Our designer lives in Mac OSX, and we don’t have Visual Studio licences for him or the content writers. And why should we have to? They’re not .NET devs!
After hacking with it for an hour or so, it looks like the freely available cross platform .NET dev tools like Visual Studio Code and Xamarin Studio won’t work for the apps we most need this for (which run .NET 4.5.1 MVC).
Thoughts on how I might resolve the tension?
One compromise might be to leave the dev site as it is and make a second staging site that is deployed through CI. That doesn’t entirely resolve everything (people would still be connecting to a shared git clone, which messes up SourceTree), but it gets us closer to where I’d like to be.
1
I would much rather have a workflow where people clone the repository, create their own branch, make changes and commit them
Absolutely they should – in my mind this is the reason for a distributed version control. If they lack confidence in the tools, a little practice should take care of that.
We’re working with one branch
I’m sure this is a hidden source of issues – don’t. Use things like Gitflow (and alternatives) and allow each designer and developer to work on their own branches (or collaborate on feature branches). You can also explore scripted pushes to the origin to assist the designers with the workflow and speed up their turn around time on an issue.
We could have them build/run the apps on their machine, but…
Do you have access to test servers for them to run a build and test it?
I think that there is even more motivation here for their own cloned repositories linked to a CI build (TeamCity and Octopus type tools would help here) and deploy to the test servers.
I’m not sure the resources you have available, but you could also explore Azure based servers etc. Given they have Macs, you could also run VMs on them. I use VirtualBox based test machines much success. This also touches on the compromises you mention, it is all a case of balancing the resources currently available against any new additional expenses.
… we don’t have Visual Studio licences for him or the content writers. And why should we have to? They’re not .NET devs!
Again, this may be dependent on the size of the team etc. but it may be worth your while to explore the Visual Studio Community Edition (it is free, but there are limitations) that may be enough for the designers to use.
7