161 reputation
7
bio website dougmcdonald.co.uk
location UK
age 31
visits member for 2 years, 3 months
seen Apr 8 at 11:19

.NET Web developer from the South West UK with an outside interest in PHP/MySQL Javascript and anything else which seems fun!


Apr
8
awarded  Scholar
Apr
8
comment Incrementing version - During development? or after release?
Thanks for the response, I can see the benefit in incrementing the version number to the minor number the system is 'going to be', rather than 'is currently', seems a sensible approach.
Apr
8
accepted Incrementing version - During development? or after release?
Apr
8
awarded  Editor
Apr
8
comment Incrementing version - During development? or after release?
@gnat I'm not asking any of the four questions on the post you linked
Apr
8
comment Incrementing version - During development? or after release?
@KilianFoth I suppose I do care as to the 1.1.x.x values as per the flip side of the pro for option 2 in the edit. Perhaps this is misplaced worry?
Apr
8
comment Incrementing version - During development? or after release?
@jonrsharpe I've added the pros and cons as I see them.
Apr
8
revised Incrementing version - During development? or after release?
Edited to include pros and cons as I see them
Apr
8
asked Incrementing version - During development? or after release?
Jan
22
comment Architectural / Application Practices to guard against 'breaking changes'
Yeah the edmx merge is a pain, we tend to use database projects to ensure we can merge more easily and then update the edmx from the db itself. Typically for example I'd do this: 1. Accept the incoming edmx 2. Merge changes in the db project, where it's easier to see changes. 3. Update my local db to bring in the new db changes from the db project. 4. Update the edmx from the db.
Jan
22
revised Architectural / Application Practices to guard against 'breaking changes'
Removed C# tag
Jan
21
awarded  Commentator
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
I can see one way of working, whereby we always make sure everything 'works' but this would quite often add a significant amount of effort to the task. Take a report, during sprint one, we 'make it work' with the changes in order to remain deployable. During sprint two we make it work again with some more changes, and again in sprint 4, 5...20. At this point we've re-written the report many times, when if we had been able to wait until the end, a single re-write would have been possible.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
In a way that the amount of change needed, is not possible to deliver in a single sprint, without breaking related areas of the system. An example would be, by changing the structure of the data storage, the existing data may not be able to be displayed properly or a report no longer works as the underlying data is depend on is too different. Making the report 'work' as part of this sprint may be pointless as during the next sprint, the next change may again change the way the report needs to operate.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Excellent answer: Data - yeah we use EF and wrap repo's (generic first, then typed) Query / Tables - I like the EAV as a concept, but with my DBA hat on I cry a little bit! We have a simplified EAV design going on with this bit of work, and pivoting some things may well help (but would obviously require major rework in queries, and possibly require logic pushed into views etc or quite a lot of complex EF code as we compose the more detailed queries). The system is relatively complex and we have hit the limit on EF a few times and had to end up in SQL directly :( Good advice though, thanks
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Yeah I get what you mean, I think this is more than the collection of stories is the entire workpackage, which could take several months. The code, during this phase would be non-deployable but we have other work during this period on the same project which does need to be deployed. As a result, I'm looking for approaches which could allow parallel development and retain the ability to deploy, during a potentially unstable state for 'some' of the code.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Interesting answer, this sits with my current thinking in that there isn't an easy way to accommodate changes which impact vertically. Annoyingly, although I can divide the changes vertically into stories, the completion of one (or even a collection) of stories, doesn't leave the user in a working state. I'm wondering if the best approach at the moment is to split the changes into 'breaking' and 'non breaking' and incorporate the 'non breaking' into the main development stream, with 'breaking' as it's own arm.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Yeah I guess that could be true, I think I was thinking that the code itself 'is' (to an extent) maintainable, but are there any ways of managing two parallel versions of code, without impacting on the ability to deploy. One option would be to develop a second version alongside, e.g. via branches. Whereas another option may be to duplicate the code and feature flag one, until the second is complete.
Jan
21
awarded  Student
Jan
21
asked Architectural / Application Practices to guard against 'breaking changes'