Slightly OT: Looking for git/development strategy suggestions for single developer
-
- KVRist
- Topic Starter
- 134 posts since 13 Apr, 2016
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!
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!
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
The usual development strategies apply. Feature branches, commit often, bug tracking...
Check git workflow for an efficient development process.
Check git workflow for an efficient development process.
-
- KVRer
- 9 posts since 30 Sep, 2010
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
-
- KVRian
- 621 posts since 28 Feb, 2011 from Sweden
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
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
-
- KVRian
- 621 posts since 28 Feb, 2011 from Sweden
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.
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
- KVRAF
- 15206 posts since 8 Mar, 2005 from Utrecht, Holland
Haven't you automated the build and managed it's dependencies through something that's also in the git repo?? If you had, then branching off an ancient commit would warp all that back in time as welljoshb 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.
We are the KVR collective. Resistance is futile. You will be assimilated.
My MusicCalc is served over https!!
My MusicCalc is served over https!!
- KVRist
- 160 posts since 26 Sep, 2001 from Paris, France
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.
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.
Lorcan | lmdsp audio plug-ins
- KVRAF
- 15206 posts since 8 Mar, 2005 from Utrecht, Holland
Maybe you want a bug/issue tracker that is open to (un)registered users as well.joshb wrote:I'll need to deal with multiple bug fixes from customers as well as adding new features and who knows what else.
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.
My MusicCalc is served over https!!
My MusicCalc is served over https!!
-
- KVRAF
- 2256 posts since 29 May, 2012
You are very lucky. Software is created alone and destroyed together. That's its nature.I've never been part of a team of developers
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~
-
- KVRian
- 621 posts since 28 Feb, 2011 from Sweden
"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.
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
-
- KVRist
- Topic Starter
- 134 posts since 13 Apr, 2016
This is interesting. Could you elaborate on this? I'm not much of a git expert at all.BertKoor wrote:Haven't you automated the build and managed it's dependencies through something that's also in the git repo?? If you had, then branching off an ancient commit would warp all that back in time as welljoshb 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.
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.
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
You can use git submodule, Google's repo or other tools to handle these dependencies.
- KVRAF
- 15206 posts since 8 Mar, 2005 from Utrecht, Holland
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)
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.
My MusicCalc is served over https!!
My MusicCalc is served over https!!