canonical-ci-engineering team mailing list archive

[Ursula Junque <ursula.junque@xxxxxxxxxxxxx>]

On Wed, Apr 1, 2015 at 7:02 PM, Thomi Richards <thomi.richards@xxxxxxxxxxxxx
> wrote:

> Hi,
>
> On Thu, Apr 2, 2015 at 9:58 AM, Ursula Junque <ursula.junque@xxxxxxxxxxxxx
> > wrote:
>
>> I think Celso has a point: we have lots of things in place but very few
>> of them seem to be "production ready". We might not be giving proper
>> attention to finishing things before starting others, *as a team*. It was
>> even raised during the retrospective that if we finished a component and
>> everything that entails, adjusted it and then moved to the next, we would
>> end up with better results. Not doing this was one of the reasons we had
>> things partially completed last sprint, and I believe we still have time to
>> avoid the same to happen in this one.
>>
>>
> I remember that discussion point.
>
> I don't think it's realistic to finish one service, then move on to the
> next. What does "finished" mean? We're constantly discovering things we
> should improve, or should have done differently as we deploy / test / break
> our services (not to mention "as we learn more about micro-services"!).
> Additionally, these services talk to each other. Sometimes we discover new
> requirements for 'component A' only after we've built 'component B' and
> 'component C'. Sometimes we discover new requirements for the services only
> after working on the deployment code... everything is related to everything
> else, you can't isolate these components :D
>

Yeah, I have failed to express the full idea and conveyed the wrong thing,
sorry. You are right, there is a middle ground between total isolation and
total dependency, that's what we decided during the retrospective we would
be trying to do: trying to get as complete as we can, considering all
relevant aspects, before we move the focus to something else.


>
> 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).



>
> What I'm aiming for is that when we discover something we should have done
> differently ( "Oh shit, we really should be rotating our log files", "or
> no, our message retry policy needs to be tweaked", "nuts, the worker names
> we're using in our services are not descriptive enough", "crap, we're not
> logging certain events which make debugging failures difficult by looking
> at logstash"...) we can make those changes quickly (at least some of the
> time), rather than thrashing around creating dozens of merge proposals
> which is error prone and slows us down.
>

I don't think we disagree here, it's more a matter of leveraging how much
tech debt this creates vs. how much working on this affects the sprint
outcome. It's always up to the team to decide if such things could be
addressed during the current sprint, I was trying to shed a light on the
other things that should be considered while doing so.


>
>
>> I'm not saying this is not an important discussion to have, I'm only
>> questioning if this is the most important discussion to have now. If you
>> compare it to the other things we still have to do, is this really the most
>> urgent problem we have?
>>
>
> 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. :)



>
>
>> Is it that certain that we will have problems and that a library *now* is
>> a solution to these?
>>
>
> Yes. the list above is a _partial_ list of some of the things we've had to
> fix in this sprint already. Most of them would have been fixed faster if we
> had infrastructure components in a shared library.
>
>
>> If the answer is yes and we have data to back it up then fine, if not, we
>> might have other problems that need addressing first. Again, I'm only
>> raising another aspect to consider the priority of this discussion, not
>> saying it's not relevant at all.
>>
>
> 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?

Cheers,


-- 
Úrsula Junque
Ubuntu CI Engineer

ursula.junque@xxxxxxxxxxxxx
ursinha@xxxxxxxxxxx
ursinha@xxxxxxxxxx

Ubuntu - "I am what I am because of who we all are."
Linux user #289453 - Ubuntu user #31144