I have a developer new to the team who has an extensive system
administration background. Due to various factors he has been working on
our build processes
rather than writing a lot of code initially. He mentioned that he
enjoyed taking this approach because it was a "good bridge" to writing
code.
That comment caused me to reflect on whether this might be a good introduction for all new developers. It seems like it, because the end product is what is important to our customers, not how elegant or innovative the underlying code is. Yes, of course, there is great value in well-written, high-performance code but that won't matter if the deliverable is defective to such a degree that the customer rejects it.
So how can one defend against distasteful defective releases? Configuration management is a set of practices that attempts to improve software quality. One of the important principles of configuration management is the concept of repeatable, reproducible builds. A continuous integration (CI) system gets you started down that path by eliminating the disruptive variables associated with the vagaries of what is installed on a developer's machine.
Setting up a build server as part of your CI system isn't a turnkey process however. One frequently needs to rewrite some code or reconfigure dependencies so that the application can be built in isolation on the build server, free from any detritus tied directly to a specific development machine. Once you get to that point you probably start realizing that you should have made some choices differently in the application. Essentially you're working from the outside in, and this viewpoint is really important. Think how much more efficiently the development team can work if projects are initiated with the goal of cleanly building on the build server rather than chasing down build issues specific to one person's development environment. The exercise of having new developers work within the configuration process earlier in their tenure rather than later resonates with me. Understanding the meta pieces that form the application is critical to deploying it, whether it is developers doing the deployment or a release engineering team.
I am more concerned about getting the release right than anything else. Having new developers- even seasoned developers, for that matter- understand the importance of writing code that fits easily into a CI environment is invaluable. For me, this holistic view of the code pays dividends in efficiency and quality.
Originally posted on LinkedIn.
That comment caused me to reflect on whether this might be a good introduction for all new developers. It seems like it, because the end product is what is important to our customers, not how elegant or innovative the underlying code is. Yes, of course, there is great value in well-written, high-performance code but that won't matter if the deliverable is defective to such a degree that the customer rejects it.
So how can one defend against distasteful defective releases? Configuration management is a set of practices that attempts to improve software quality. One of the important principles of configuration management is the concept of repeatable, reproducible builds. A continuous integration (CI) system gets you started down that path by eliminating the disruptive variables associated with the vagaries of what is installed on a developer's machine.
Setting up a build server as part of your CI system isn't a turnkey process however. One frequently needs to rewrite some code or reconfigure dependencies so that the application can be built in isolation on the build server, free from any detritus tied directly to a specific development machine. Once you get to that point you probably start realizing that you should have made some choices differently in the application. Essentially you're working from the outside in, and this viewpoint is really important. Think how much more efficiently the development team can work if projects are initiated with the goal of cleanly building on the build server rather than chasing down build issues specific to one person's development environment. The exercise of having new developers work within the configuration process earlier in their tenure rather than later resonates with me. Understanding the meta pieces that form the application is critical to deploying it, whether it is developers doing the deployment or a release engineering team.
I am more concerned about getting the release right than anything else. Having new developers- even seasoned developers, for that matter- understand the importance of writing code that fits easily into a CI environment is invaluable. For me, this holistic view of the code pays dividends in efficiency and quality.
Originally posted on LinkedIn.