Although we have thousands of engineers and products, we can achieve a high release velocity because individual teams can decide how often and when to release new versions of their products. Release engineering has developed best practices and tools that allow our product development teams to control and run their own release processes. In order to work at scale, teams must be self-sufficient. Release engineering is guided by an engineering and service philosophy that’s expressed through four major principles, detailed in the following sections. In order to make sure our release processes meet business requirements, release engineers and SREs work together to develop strategies for canarying changes, pushing out new releases without interrupting services, and rolling back features that demonstrate problems. Google has a large number of SREs who are charged with safely deploying products and keeping Google services up and running. Making sure that our tools behave correctly by default and are adequately documented makes it easy for teams to stay focused on features and users, rather than spending time reinventing the wheel (poorly) when it comes to releasing software. Examples include compiler flags, formats for build identification tags, and required steps during a build.
Our best practices cover all elements of the release process. Release engineers define best practices for using our tools in order to make sure projects are released using consistent and repeatable methodologies.
Most of these tools were envisioned and developed by release engineers.
#GOOGLE PROCESS MODELING TOOLS CODE#
We have tools that report on a host of metrics, such as how much time it takes for a code change to be deployed into production (in other words, release velocity) and statistics on what features are being used in build configuration files. Google is a data-driven company and release engineering follows suit.
#GOOGLE PROCESS MODELING TOOLS SOFTWARE#
Release engineers work with software engineers (SWEs) in product development and SREs to define all the steps required to release software-from how the software is stored in the source code repository, to build rules for compilation, to how testing, packaging, and deployment are conducted. Release engineering is a specific job function at Google. SREs care about this process from source code to deployment.
Site Reliability Engineers (SREs) need to know that the binaries and configurations they use are built in a reproducible, automated way so that releases are repeatable and aren’t “unique snowflakes.” Changes to any aspect of the release process should be intentional, rather than accidental. Running reliable services requires reliable release processes. Their skill set includes deep knowledge of multiple domains: development, configuration management, test integration, system administration, and customer support. Release engineers have a solid (if not expert) understanding of source code management, compilers, build configuration languages, automated build tools, package managers, and installers. Release engineering is a relatively new and fast-growing discipline of software engineering that can be concisely described as building and delivering software.
0 kommentar(er)
