canonical-ci-engineering team mailing list archive

[Thomi Richards <thomi.richards@xxxxxxxxxxxxx>]

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 <ursula.junque@xxxxxxxxxxxxx>
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
thomi.richards@xxxxxxxxxxxxx