Mathematical Computerscientist, father and nerdy guy next door who loves to fix stuff.
I work as Technical Lead for Roomle and servant to my 18 month old son. Besides that... there is hardly enoug...
I am totally with you about all the problems you stated. Specially the thing about that damn DB script. that's always a big scary point in going into production: "we didn't miss any DB update right?". What we do regarding the different repos: frontend and API are different stories dependent on each other. Whenever possible we ensure that stories in the frontend who rely on a backend-story don't make it into the Sprint as long as the backend is not on production. Meaning we try to break down stories to the minimum deployable unit. So you focus on one thing during development and dependencies are sorted out by mid term planning.
Mathematical Computerscientist, father and nerdy guy next door who loves to fix stuff.
I work as Technical Lead for Roomle and servant to my 18 month old son. Besides that... there is hardly enoug...
sorry, got carried away by the repo-part. How I work thru a story? If it's not clearly defined, it doesn't make it thru estimating and planning. So I start defining which parts it touches (data layer, utils, buisness logic...) and then work my way up: write tests that define the behaviour, write code till tests are green, create pull request, next layer. If a pull request depends on one of a lower layer I mark it WIP with a reference to the version/pull request it's depending on.
Mathematical Computerscientist, father and nerdy guy next door who loves to fix stuff.
I work as Technical Lead for Roomle and servant to my 18 month old son. Besides that... there is hardly enoug...
I am totally with you about all the problems you stated. Specially the thing about that damn DB script. that's always a big scary point in going into production: "we didn't miss any DB update right?". What we do regarding the different repos: frontend and API are different stories dependent on each other. Whenever possible we ensure that stories in the frontend who rely on a backend-story don't make it into the Sprint as long as the backend is not on production. Meaning we try to break down stories to the minimum deployable unit. So you focus on one thing during development and dependencies are sorted out by mid term planning.
sorry, got carried away by the repo-part. How I work thru a story? If it's not clearly defined, it doesn't make it thru estimating and planning. So I start defining which parts it touches (data layer, utils, buisness logic...) and then work my way up: write tests that define the behaviour, write code till tests are green, create pull request, next layer. If a pull request depends on one of a lower layer I mark it WIP with a reference to the version/pull request it's depending on.
How big is your team?
The whole team is roughly 8 devs. But on different technologies (web, iOS, Android, backend, 3D, core)