Is it or can it be a Scrum Master's responsibility to:
- setup/improve a code review software system?
- setup/improve the continuous integration process?
- provide scripts/macros/helper tools to make the development process easier/more efficient ?
No, no, and no. These responsibilities rest with the self-organizing development team. If you turn the Scrum Master into a DevOps engineer, that person will no longer be able to focus on the core responsibilities of the Scrum Master role.
The Scrum Master Role
The Scrum Master is the shepherd and evangelist of the Scrum process. In other words, the SM acts as a process referee, and "removing impediments" generally refers to working with the team, management, and the stakeholders to raise the visibility of process-impeding issues and providing a constructive framework for all parties to cooperatively develop an organizationally-appropriate solution.
The Team's Responsibilities
If a Sprint Retrospective identifies code review as a process issue, then the Scrum Master should capture that issue and provide guidance to the team and the Product Owner on how the framework allows them to improve that part of the process. This may include:
- changing the "definition of done" to incorporate code review processes,
- the Product Owner adding a new user story to Product Backlog that prioritizes the installation and configuration of a code review system, or
- anything else that everyone agrees fixes the issue for the team and the project.
The same is true for continuous integration and tool chains. Whether driven by technical debt or a desire to continuously improve the process, the Sprint Retrospective is the place to raise such issues.
Ultimately, it is the Product Owner's responsibility to prioritize the work related to process improvement (by manipulating the Product Backlog), and the team's responsibility to implement a solution once that work has been prioritized by the PO.
The Scrum Master's job is just to make sure that the Scrum framework is properly leveraged to give everyone involved the process tools that they need to do these things within the context of Scrum. If you take your Scrum Master off-task by assigning implementation work, then that person is no longer fully-dedicated to performing the tasks that are essential to the Scrum Master role. Don't do that.
Intra-team process and technical implementation are responsibilities that rest within the self-organizing development team. Neither the Scrum Master nor the Product Owner should be sticking their thumbs in those particular pies.