Question: How does the risk and compliance team monitor the backlog?
Answer: We actually get the team to highlight the changes that they believe are risky and then we monitor those ones. The teams often have a better idea of what is risky than the risk team.
Question: How do you decide what is okay to be good enough?
Answer: We risk assess the downside - how many customers will it affect, how big an impact could it have, can we back out the change easily? And then we balance that against the benefit we will get from releasing the development to production. Sometimes we will limit the number of customers by only releasing to a subset of customers - seeing how that goes and then opening up to a wider group.
Question: Does your peer review have a checklist?
Answer: We don’t use checklists for our peer review - there are two reasons - the first is that it stops or reviewers thinking - they tend to follow the checklist and the second is that it would end up being part of the audit control and at some point someone will not tick all the things on the checklist and so we would fail the audit.
Question: How did you convince the auditors that this was okay?
Answer: We talk to them about the risks associated with change and what the compliance obligations required - there is nothing saying the level of removal from the person making the change - just that it needs to be signed off by someone other than the person making the change. And when we talked to them about the change approval boards they tended to agree that this was often a rubber stamp on the change. We also got them to meet some of the teams that do these changes and the people that actually do the peer review and they realized how engaged the peer reviewers were in the task.
Question: If "your name is on a review", how to make sure the responsible people do not see that as a barrier to sign it?
Answer: We find that the team members will review the code if they know what they are reviewing. If they feel that they don't know what the change is doing or don't understand then they will either - say that they want someone else to review it or - they will work with the person that made the change to understand what the change is and how it works. Because the teams are smaller and they are working in the code all the time they have a better level of understanding of the code and also the engagement is higher.
Question: Is there a webinar planed which show more in detail how i can use the tools? like how to setup reviews for example?
Answer: We are currently developing the runbooks to show how to set up the compliance settings in Bitbucket and Bamboo and once these are ready we will share them on the community.
Question: Is it possible to get your slides?
Answer: We will email the on-demand version of this presentation to everyone who registered within a week after the event.
Question: Your process seems to depend on high test coverage, are you monitoring test coverage / are there checks in place when test coverage lowers
Answer: The automated tests that we run for each commit are held within Bitbucket and are subject to peer review checks (just like the code). If someone wants to change the tests they will need to get that peer reviewed before it will be changed. We monitor the settings around build tests as well - if someone wants to turn off the green build check the risk and compliance team are notified and we ask the person's manager why they needed to do this.
Two weeks left in our Open DevOps partner spotlight - and we’re excited to be shining a light on CI/CD. A foundational piece of DevOps, CI/CD needs no introduction… but we’ll give one anyways! Cont...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events