Hi, I mostly agree with you, so I'm trimming some of your mail to just the bits I have comments for:
On Thu, Apr 2, 2015 at 11:54 AM, Ursula Junque <[email protected]> wrote: > > >> Software is never "done", it is sometimes "done enough to be used". >> > > I agree :) But for sprint purposes we *have* to have a definition of done, > otherwise, for the very same reason, we would never be done with a story. > :) For us, there has to be a definition of "enough", and we're not there > yet when it comes to defining a good set and sticking to it, we still > overlook things. That was the point I was trying to make, and I believe > what Celso might be trying to say there (he can correct me if I'm wrong). > > I worry that sometimes we lose sight of the fact that after the sprint is completed, this code doesn't go away - we still need to support it. The acceptance criteria we have today may be enough for our stakeholders to say "yeah, this is good enough, we'll use it", but might not be good enough to ensure ongoing trouble-free support. I'd like to see some acceptance criteria regarding making sure we can continue to evolve and support this code well into the future. For me, that means: don't duplicate code, have tests, define and adhere to standards across our services. Perhaps some of the consternation my proposal has given rise to is due to the fact that these concerns aren't codified in acceptance criteria? How does one word such an acceptance criteria? Isn't this a sort of cheat, given that our stakeholders haven't asked for this? <snip> >> We have many problems we need to solve. IMO our deployment & runtime >> testing is the biggest thing that needs to be solved, but this is a close >> second. I have no idea about the CD issues - I mean, I have ideas, but the >> intended design for that system is rather opaque to me. >> > > If that's opaque, then let's make it clear. Let's raise such things and > solve them, CD is a *team's* problem, if that's not what it looks like then > we should fix it. :) > > Yes please. I'd love to know how our CD system is supposed to work. In particular, I'm not sure of a few points: * How should CD interact with the development cycle? phrased differently: as a developer, how do I get told that the thing I just proposed for merging is horribly busted and doesn't deploy cleanly? * How should CD interact with ops? How should we be notified of some runtime issue? How does CD learn about runtime issues? * How will CD serialise and handle multiple upgrades? for example: what happens if we need to roll out component_A and component_B in an atomic operation? What should it do if component_A has several revisions that can be deployed - deploy them all at once, or deploy them one at a time? Perhaps we need to answer these questions in the normal scrum sprint process (i.e.- actually plan it as a story, so we know what we're aiming for)? Maybe I'm missing something, but a CD solution that does what we want seems like a far more difficult and complex task than actually building these services (maybe we need a sprint for the CD alone?). I'm aware that we ought to be favouring 'working software over comprehensive documentation', but I think that in this case a bit of planning and documentation would make this product a lot clearer. <snip> >> I think we should be able to multi-task here (as a team, I mean, not as >> individuals). >> >> Celso cares about the deployment side of things (or at least seems to, I >> don't want to put words in his mouth), and has been (and I'm sure will >> continue) doing a great job getting our deployment story robust & complete. >> >> I care about the quality of the code and our ability to create new >> services quickly, so that's where I'm going to focus. >> > > I think Francis explained well why we don't think this is a good idea, we > are finally moving away from exactly that ("I care about this, you care > about that, oh btw Celso was hit by a bus and now we need two weeks to > figure out how to CD things"). The idea is to really "scrum" around a > problem, even if the team doesn't have the ability to fix it, it should at > least care enough to bring things into attention. I believe that's what > Celso was doing, and I tried to do myself: we have to care about delivering > stories as a team, what should we consider now to make that happen? > > Yeah, I phrased that poorly, sorry. I didn't mean to imply that Celso *only* cares about CD, or that I *only* care about our service code quality, but rather that we both seem to have been concentrating on those areas till now. I understand enough about the core-* services to be able to dive in and implement them - there's a card on the backlog, task cards, architecture notes etc. In contrast, there's no backlog card for the CD work (except for https://trello.com/c/4UuSk2dD/59-1-improve-infra-cd-pipeline-to-stackystack but that doesn't make any sense to me, and it's marked as 'DONE'), no acceptance criteria, and while we've been talking and documenting ideas around testing, I'm not aware of any proposal for how we should build this thing from an architectural POV. We're now several degrees off the original topic, so I'll try to bring us back to the beginning: My proposal to move some shared infrastructure components into a library was met with two primary concerns: 1) That doing this might not be the most important thing to do in order to fulfil our current acceptance criteria. I think this concern is actually correct, but I think our acceptance criteria need tweaking (as above). 2) That doing this will distract us from solving the CD issues, and the related concern that we never got one service completed to the point of having confidence in it's HA. Again, this is probably a valid concern, but I'm not aware of a concrete plan for our HA story - we're still discussing it on a day-to-day basis. I think it's unfair to say "we should have completed the CD story first" when it's not even planned fully yet. FWIW, I'm enjoying the work we're doing. micro-services are a new concept to us all, I guess, so there's bound to be some ... teething problems. On the whole I think we're doing about as well as we could reasonably expect at this point. I'm also enjoying this discussion, since it gives us a chance to discuss our sprint planning before the retrospective. Cheers, -- Thomi Richards [email protected]
-- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
