Slightly OT: Looking for git/development strategy suggestions for single developer

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Hey gents,

I'm about to start beta-testing my plugin next week, with an actual product release sometime after that, and it occurs to me that I could use some advice on how to stay organized for the future. I'll need to deal with multiple bug fixes from customers as well as adding new features and who knows what else.

I've never been part of a team of developers and never actually released a product that will require proper support like this, so I thought I'd ask. I'm not sure what to expect so it's hard to think of an appropriate strategy going forward.

Besides my own code base, I'm using JUCE so I also have to think about which version I'm using at any one time and how that relates to which branch/version of my own code. Oy vey.

So you can see why I want to keep things as simple as possible.

I know this is a pretty open-ended question, but any advice from similar developers would be very helpful.

Thanks!

Post

The usual development strategies apply. Feature branches, commit often, bug tracking...
Check git workflow for an efficient development process.

Post

Gitflow is probably the best choice. There are plugins available to make it a bit easier. Looks like this: http://nvie.com/img/git-model@2x.png

Post

My development strategy when working solo on projects like my plugin where there will be no other developers is very much more loose than when I'm working with others.
I'm using git of course but don't really care if I'm doing stuff in parallell or whatever.
I just keep notes of TODO's in an Evernote-note och when they are done I move them to DONE. Really keeping it simple.
To keep track of which JUCE version I'm using I have JUCE checked out per plugin project in a git subrepo.
https://github.com/ingydotnet/git-subrepo
David Guda gudaaudio.com

Post

I think this btw is not a all off topic in a plugin development forum.
Not every topic has to be super detailed DSP stuff about feedback-shaping in topology preserved zero delay feedback filters of some kind few have even heard of.
David Guda gudaaudio.com

Post

joshb wrote:Besides my own code base, I'm using JUCE so I also have to think about which version I'm using at any one time and how that relates to which branch/version of my own code.
Haven't you automated the build and managed it's dependencies through something that's also in the git repo?? :shock: If you had, then branching off an ancient commit would warp all that back in time as well ;-)
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post

A flat list of TODO's is nice at the start, but it quickly gets messy when it grows.
With a proper bugtracker you can organize things by topic, priority, and even track the time you spend by task.

For example, you might grow a list of ideas for improvements and new features that cannot all be implemented at once,
plus once your product is released you'll probably have all sorts of bug reports and feature requests starting to pile up,
and a tracker will definitely help things stay manageable and organized.

I use http://www.redmine.org/, it's very stable and has every thing I need, plus it's free and actively developed.

Post

joshb wrote:I'll need to deal with multiple bug fixes from customers as well as adding new features and who knows what else.
Maybe you want a bug/issue tracker that is open to (un)registered users as well.

Eg https://www.atlassian.com/software/jira and there's much more like that out there (Bugzilla, Trac, Mantis...) Or maybe use GitHub? Private repo for your sources & gh_pages, public repo for issue tracking and a wiki.
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post

I've never been part of a team of developers
You are very lucky. Software is created alone and destroyed together. That's its nature.
So called "team work" is emulation of work that is done alone by isolating modules and minimizing the interface between.
I had recently seen a video about how to play the piano on youtube about hand independence. The author had a nice view of it. He first postulated that hand independence is nonsense and further claimed that the only way to play the piano is by not playing it (around 9:30). That's insight :-) It's also how you do "team work"

https://www.youtube.com/watch?v=W4qPv7wWoQ8
~stratum~

Post

"Flat" TODO list is not at all unorganized. I order things most important first least important on the bottom and constantly rearrange as needed. Bug fixes tend to go on top etc.
Most entries only need one line very much because I am the only developer, so I know exactly what information that is implied and what has to be explicit. It doesn't have to be very formally written etc.
Software developed with teams don't have this luxury, what is a one line TODO for me becomes a full JIRA ticket with full explanation and the overhead of going through a project manager or through a scrum team backlog etc before being able to start work. Just creating a ticket like that is quite a few clicks and is more rigid.
Many TODOs I write is written in the middle of working on another (oh yeah, I need to do that as well, but now now) then just a quick brain dump on the TODO list and back to the code within a minute, short enough to not loose speed on the current task.
Don't throw away that luxury of cheap task switching if not needed.

Going through the TODO list, cleaning up, moving around TODOs can be done when tempo is down in coding or whatever reason.

The way I see it, bug trackers are necessary evils of working with teams.
David Guda gudaaudio.com

Post

BertKoor wrote:
joshb wrote:Besides my own code base, I'm using JUCE so I also have to think about which version I'm using at any one time and how that relates to which branch/version of my own code.
Haven't you automated the build and managed it's dependencies through something that's also in the git repo?? :shock: If you had, then branching off an ancient commit would warp all that back in time as well ;-)
This is interesting. Could you elaborate on this? I'm not much of a git expert at all.

Currently, I have JUCE checked out on my local drive in a separate directory and every project I have all point to that directory. But I only have the one real project that I'm releasing at the moment...everything else is just test code.

But it occurs to me that I'll more than likely start another real project using JUCE and that *may* require me to use different versions of JUCE at one time. I hadn't thought of that.

Post

You can use git submodule, Google's repo or other tools to handle these dependencies.

Post

I don't know the specifics of JUCE, but usually you'd get/resolve your depencencies from some sort of central repository. NuGet for C# libraries, Maven Central for java jars, etc.
In your project there should be something like a properties file (or xml) (this should be stored in your Git repo!) that declares what libs your project is depending on, and exactly what version it would be. Then your build tool should do that work.

In case you compile your dependencies yourself from code, that could be made a seperate build task which ends up with putting the .dll in a local repository of your own (or the GAC, that is a repo as well)
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post Reply

Return to “DSP and Plugin Development”