Hero numbers - Build Manager
They talk so much about system administrators, developers, testers ... I wanted to talk about those without whom no enterprise development can do. Build Manager, also known as the Release Engineer, remains a hero in the shadows - few people know about it. Who is he
This is one of my first publications online. I do not claim to be a specialist in the field in question, and in no case do I position the article as a guide to action. I just tried to put together my little experience, and I want to try to share my thoughts with the community.
All is well, while the product is small. While a small team, and all each other know in person. But as soon as the product grows to several dozen hefty modules, each of which is occupied by a separate development team, and a separate QA team is allocated for the most important modules - everything becomes very sad. In development, methodologies are beginning to be applied, for example Scrum. Product instoller begins to develop a separate team. The product itself weighs more than 2GB, and the compilation takes about three hours. Assembling the distribution kit of the product for end users has long ceased to be a trivial task, because many customers have personal features or patches that are not made to the mainstream, and the development of the main modules of the product is completely independent. By this time you can hardly find a person who remembers this product in the bud, and went along with it all the way. It's time to do something with it, namely, to create a new team. Let's call it Build Factory.
')
What can this team do? Development. Only not the product itself, and not the installer, but the so-called Build Framework. It's time to start keeping documentation, invent rules, which module to build for which one, and how to pack it all later in an installer. Well and, accordingly, automate the entire process. This is called Continious Integration. Consider in more detail.
Build Factory can take the following responsibilities:
Of course, everything depends on the project specification, the language, the chosen development methodology, the size of the staff, the geographical distance between the teams and other factors. But all the same, there are common features.
This approach significantly increases the speed of development. Instead of the differently assembled modules of the product, a single Build Framework assembles each module uniformly. And with the help of CI, the QA team gets a new version of the product at its disposal as quickly as possible. In other words, Build Factory helps Dev and QA teams find common language.
Disclaimer
This is one of my first publications online. I do not claim to be a specialist in the field in question, and in no case do I position the article as a guide to action. I just tried to put together my little experience, and I want to try to share my thoughts with the community.
Problem
All is well, while the product is small. While a small team, and all each other know in person. But as soon as the product grows to several dozen hefty modules, each of which is occupied by a separate development team, and a separate QA team is allocated for the most important modules - everything becomes very sad. In development, methodologies are beginning to be applied, for example Scrum. Product instoller begins to develop a separate team. The product itself weighs more than 2GB, and the compilation takes about three hours. Assembling the distribution kit of the product for end users has long ceased to be a trivial task, because many customers have personal features or patches that are not made to the mainstream, and the development of the main modules of the product is completely independent. By this time you can hardly find a person who remembers this product in the bud, and went along with it all the way. It's time to do something with it, namely, to create a new team. Let's call it Build Factory.
')
Build factory
What can this team do? Development. Only not the product itself, and not the installer, but the so-called Build Framework. It's time to start keeping documentation, invent rules, which module to build for which one, and how to pack it all later in an installer. Well and, accordingly, automate the entire process. This is called Continious Integration. Consider in more detail.
A responsibility
Build Factory can take the following responsibilities:
- Build scripts
It is no secret that for a long time the de facto standard has been to use special tools for assembly, such as Ant, Maven, CMake and others. From now on, writing and script support can be done by the Build Factory. Due to this, over time, they begin to fully control the process of integrating the modules among themselves, because earlier, when each team wrote its own script for its own module, everything was not very uniform and complicated the integration of the modules among themselves. - SCM support
Controlling product brandies, and, in fact, controlling product versioning is a task that the Build Factory can handle perfectly. Again, the versioning of the different modules of the product will look uniform, which again will facilitate the integration of the modules among themselves. - Continuous integration
This is the main part of the Build Factory. The idea is that the developers simply commit the code in SCM, no more. All the rest are engaged in the build server automatically. There are excellent CI Systems, such as Jenkins \ Hudson, Electri Commander, Cruise Control, etc ... All of them are in fact one large cross-platform scheduler with a web interface, the possibility of clustering and other buns. I can write the details in a separate article, if anyone is interested, for the time being I will say the following only for the seed. After completing steps 1 and 2, the CI System settings development process will be as follows. Developers commit code, CI System on schedule or trigger (for example, if there are new commits in SCM since the last successful build) runs unit tests, runs module assembly scripts (possibly in parallel, if the project architecture allows it), waits for the results, packs them in installer, and floods on the instal server. After the successful build on some test environment, you can also run automatic testing, which the QA team will kindly provide, as well as prepare the product for manual testing (for example, in the case of a Java web application, load the product on a test Tomcat, fill the database with test files). data and stuff like that). CI System can be used by anyone who needs it within the framework of the chosen development methodology. For example, QE, can press one big “BUILD IT!” Button, wait, and get a product ready for testing on a test server. Sometimes it is very convenient in this way, after a series of manipulations, reset the state of the product to its original state. - Search for perpetrators
When the build crashes, it is the Build Factory that is able to quickly find the one who made the fatal commit (if point 3 is done correctly). This speeds up the process of fixing and restoring the normal product life cycle. - Developer Support
It is no secret that not all developers know exactly the SCM that is used in the company. Build Factory is able to support such people, as well as organize trainings for them. - Product Releases
Depending on the development methodology, in principle any successful build can be called release. But if for some reason this cannot happen, then the Build Factory can create the special release build (and distribution kit).
What should Build Manager know
Of course, everything depends on the project specification, the language, the chosen development methodology, the size of the staff, the geographical distance between the teams and other factors. But all the same, there are common features.
- Understand how the development process takes place within the framework of the chosen methodology.
- Be able to write scripts for assembly.
- Be able to work with CI System.
- Not all tasks can be performed using build scripts or CI System, therefore knowledge of the scripting or (even better) native language is welcome.
- You need to communicate a lot, the communicative skill is very important. Just imagine, you may need to persuade several teams to immediately switch from Ant to Maven, or from SVN to Git.
findings
This approach significantly increases the speed of development. Instead of the differently assembled modules of the product, a single Build Framework assembles each module uniformly. And with the help of CI, the QA team gets a new version of the product at its disposal as quickly as possible. In other words, Build Factory helps Dev and QA teams find common language.
Source: https://habr.com/ru/post/137855/
All Articles