Hi, On Thu, Apr 2, 2015 at 9:58 AM, Ursula Junque <[email protected]> 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 Software is never "done", it is sometimes "done enough to be used". 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'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. > 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. We'll need to concentrate on both areas before we can finish the sprint, we may as well take advantage of the parallel nature of the team to get it all done. Cheeers :D -- 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
