In the thread at #542 (comment 249193093) we discussed potential overlap between Release and Configure around the deployment portion of Auto DevOps. For example, the CD team is working on gitlab-org&1804 which is about making Auto DevOps understand how container-based deployments to Microsoft, Google, and Amazon clouds work when not using Kubernetes.
It may make sense to have the CD team own all of the deployment portion of Auto DevOps, but this would need to come with a transition plan, potentially budget for hiring, and/or move of team members who were expert in the existing functionality.
This is a discussion issue for that topic
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Thanks @jlenny . I think that makes sense. Would you agree that one way to scope this is to say that the Release team drives improvements to default capabilities in the Auto Deploy template?
I think that same model applies to other stages as well, Auto Test should be of concern for Verify, Auto Build for Package, etc. However, are there specific features or improvements that are delayed because of confusion on ownership? We generally don't operate where there are prescribed owners if there is a team that considers it a priority to make an improvement.
@kencjohnston I don't think there are blocked improvements at the moment - but I also don't think other teams are thinking about improving Auto DevOps.
@jlenny @kencjohnston is there a specific reason or value to be gained in explicitly defining ownership? I think we can continue to collaborate, adding features as they align to plans for each of the stages. For example, in CI, the configure team has added features when they align to our plans (for example gitlab-org/gitlab#24021 (closed)), the release team could do the same with Auto Deploy.
One note about gitlab-org&1804 (without thorough review of the issue); I think it's fine for us to provide templates to make it easier to deploy to a certain cloud, however, we should be careful of building provider-specific deploy features that hinder portability and don't use generic constructs.
I also don't think other teams are thinking about improving Auto DevOps.
I tend to agree, I do think it is largely forgotten and there is little active development of the ADO scripts to accommodate new features as they are added. This even goes to the Monitor stage where we don't have Auto Monitor scripts that would setup some default alerts and incident templates as part of ADO. Maybe that is what we work on.
@kencjohnston I'm not sure if we are referring now to the "deploy" portion only or Auto DevOps as a whole. The auto deploy image is consistently maintained and updated to add/support new features. As a whole, we're working on making Auto DevOps better and smarter. In the last couple of releases we've added required CI functionality to run Auto DevOps conditionally. Additionally, we plan to add chaos engineering features to Auto DevOps as soon as we have litmus chaos available as a managed app. We're also planning to use CNB instead of existing buildpacks, among other improvements.
I agree that specifc "Auto Monitor" features have an opportunity to improve, and we'll look to the Monitor teams to help us out here.
little active development of the ADO scripts to accommodate new features as they are added.
@danielgruesso explicitly defining ownership allows us to map budget priorities to investment in product areas. For example, if Release has an unbudgeted responsibility to significantly add features for Configure then it makes headcount planning confusing. Small overlaps here and there seem to work fine, but if we're saying Release is going to spend a significant portion of its time in FY2021 building out Configure components then might it not have been more clear to the board/leadership if we just invested headcount in Configure? Or made it clear what Release was actually doing by having them own the thing they were doing?
@jlenny I see your point. It may be worth discussing what high level goals Release has and how advancing Auto Deploy may help getting to those goals. Overall I don't have an issue with release owning this so that it's no longer a "Configure Component" and the team can budget for it. Configure will likely continue to make improvement to it as we add features to Auto DevOps.
The ones I'm aware of are in Monitor (incidents, default alerts, etc), but I know when we add new scanners in Secure or Verify stages it is the responsibility of those stages to update the standard templates to incorporate them.
@jlenny @danielgruesso@ogolowinski - Based on what Jason said above - I do want to make sure this discussion is even warranted. Maybe some emojii voting is warranted. Can you vote with:
if we think explicit transfer is needed
if we think leaving the current scoping definition as is (and keeping our standard practice of everyone can contribute) is sufficient
@kencjohnston I would put it this way, if the expectation from leadership is that the Release team spends significant investment over the year in improving it then explicit transfer is needed, if it remains something like "if you happen to find something interesting to update in Auto DevOps feel free" then everyone can contribute is fine.
@jlenny - Gotcha, I can't speak to leadership expectations. My recollection of the history here is what you inquired about moving responsibility to the release team. If you are no longer interested in that move I'm not aware of any other driving force behind the move and we can close this issue and the discussion thread in the other issue. I'd posit that the rest of the group is comfortable with the status quo.