TFS & GO & Chef, oh my: Part 7 - Minor? setback
So due to a number of reasons I won't disclose, the process needs to change. Slightly more manual, but if GO offers the option, should be mitigated reasonably well.
Essentially the applications use stored procedures and whatnot in the DB layer - these are shared to recycle code. Unfortunately it means that we cannot simply have a pipeline for each app/svc - items must be updated together (and taken offline to do so). Something for our architecture review board meetings...
Anywho...here's the new plan:
Essentially the applications use stored procedures and whatnot in the DB layer - these are shared to recycle code. Unfortunately it means that we cannot simply have a pipeline for each app/svc - items must be updated together (and taken offline to do so). Something for our architecture review board meetings...
Anywho...here's the new plan:
- New sprint starts - PM informs us that XYZ apps/svcs are being updated
- We create a single new pipeline for the SQL scripts
- Then create a 'sprint dashboard' page with the relevant individual pipelines
- When they are ready to build, we can do each item individually (or together)
- When they are ready to deploy, we run the SQL pipeline
- This stops all relevant services/sites and runs the SQL scripts
- The buildmaster then runs the other (remaining) pipelines on the dashboard
- At the end of the individual pipelines is a service start -> run tests stage
- We then know if things are successful and can notify stakeholders
This lets us keep the existing update process, but also keep the 'installation unit' pipeline strategy.
Another method we investigated was to give up the installation unit concept and just do groups, but we felt this could get too dynamic/arbitrary - the granular IUs have little deviation.
At any rate - not the end of the world. Now to figure out if GO supports this methodology...
Comments
Post a Comment