It's not that I'm paranoid, it's just that I don't see why I wouldn't be careful
(unknown hero)
My entire development workflow is arrayed around tools I can install and maintain myself, insofar as it's possible. Especially the server side stuff. Students and clients ask, so here goes.
What are we collaborating on?
The first step and the most important one is documenting the expectations. We're about to embark on a multiple days/weeks/months journey together, and we hopefully agreed on what should be done. Right now we shake hands, and I'm already sure that the variations in our respective minds have already started to add up.
The first step is to get all the conception documents and all the available documentation which we validated into a shared space. Git repo, wiki, shared folder, anything that is accessible at any time to avoid the "by the way, what did we decide on X?" question when crunch time occurs. If we have already taken a decision, it goes into the shared documents. If not, we decide, and then it goes into the shared document.
Versionning / Issues
I use a self-hosted instance of Gitlab, which gives me git (obviously), but also issues in list or kanban forms, and access to CI/CD (more later), as well as a wiki. My code, and my customers' data, matter to me. It's not that it's a secret, just that I want to be able to control access.
For commits and tasks, I use Git Flow, or slight variants of it. It makes for easier collaboration if it's a multi-dev project, and allows for easier tracking of issues.
Speaking of issues, back before Agile was so heavily codified, a simple 4 boards system works just fine
- to discuss
- to do
- doing
- done
I guess I could split boards between various domains as well, but I use tags for that (UI, back, etc). It shows at a glance where I am on my project.
Testing, CI/CD, all that jazz
Up till this point, most people were probably nodding along, or arguing about tiny points of detail. The problem with testing (unit tests, UI tests, beta tests, etc etc etc) is that it's heavily dependant on what you are trying to build. If there's an API, then by all means, there should be unit tests on it. Otherwise...
The bottomline for me is this: if there are several people on a project, I want clearly defined ownership. It's not that I won't fix a bug in someone else's code, just that they own it and therefore have to have a reliable way of testing that my fix works.
Coding is very very artsy. After a while, you can recognize someone's coding style. Anyone who had to dive into someone else's code know that it's very hard to mimic exactly how the original author would have wrote.
Tests solve part of that problem. My code, my tests. If you fix my code, run my tests, I'm fairly confident that you didn't wreck the whole thing. And that I won't have to spend a couple of hours figuring out what it is that you did.
At interface points too, tests are super useful. Say I do that part of the app and you do that other part of the app. If we agree on how they should communicate, we can setup tests that validate the "rules". Easy as that.
For mobile app development, the biggest hassle is getting betas in the hands of clients/testers. Thankfully, between testflight, fastlane, and all the others, it's not that complex. The issue there is automating the release of new betas. I used to use Jenkins, but sometimes, the stuff in Gitlab itself is enough. Mileage will vary.
One thing's for certain: if you test manually your code, it's either a very very very small and simple project, or you're not actually testing it.
Chat / communications
Email sucks. I log in my computer, see 300+ emails, and am very quickly depressed. SMS/iMessage is for urgent things.
Back in the day, I would have used IRC, for teams. Slack came along and everyone uses it. But Slack comes with a lot of unknowns. The gitlab omnibus installation comes with Mattermost, which is like slack, but self-hosted. Done.
