In our agile development process developing software at high velocity with good quality is already there.
However as Macaulay Culkin is the only one good in "home alone" style. Working with other teams as testing and operation can be tough and iterating again and again in release testing and launch doesn't work very well at my company and project.
I am seeking for any means to revolutionize the release and launch process from a feature being code-complete to being available to customers.
@8:38 - big bang releases are bad, small deltas are cool! Release in incremental fashion.As I understand recommended further readings are
Probably replacing subsystems while running could do the trick?
@10:35 - this reflects also real project progress
done is nothing else than done. anything less is not done!
manifesto: satisfy the customer early and continuous delivery of valuable software
this is a team metric!
@13:00 - create a completely automated system to test if code is production ready
==> code will be always production ready.
no one is done until sw is done!
everyone is on the topic to make the product production-ready
@15:00 - project teams are created, then after sw is ready, project team is dismantled, operation team is created. huge barrier, huge waste.
product team shall be created: developers, testers, operation people.
cross functional teams are essential.
@19:22 - deployment pipeline, automated acceptance tests, then user acceptance tests
fast feedback!
@23:10 - if it hurts, do it more often and bring the pain forward
create a repeatable, reliable process for releasing
automate (almost) everything!
everyone is responsible for quality & testing: developers, operation (project managers, business analysts, CEO)
if something fails: everyone should focus on the problem
done means released
continuous improvement - do not make one big step now, it will not work!
@26:10 - "how long would it take your organization to deploy a change that involved just a line of change?"
(cycle time)
@27:50 - build binaries once, include config data separately.
bad clearcase model: build again-and-again.
@31:00 - continuous integration = working on main line
branching is bad, causes major bugs
@36:00 - testers should not do any regression testing! it must be automated
@37:00 - canary releasing, release to a small set of users. (A-B testing)
small set of users are redirected to version+1
use only high quality - do not use this for testing!
(my question: how to use data migration / data schema changes? we should separate A-B users completely beforehand? should not use same data tables for data ids? e.g. primary keys for result raw tables)
No comments:
Post a Comment