One of my team maxims is "Deploy Early and Often." As soon as a minimum viable product is available I want it off the developer's machine and deployed to a server, device, or wherever the final destination is.
Somewhat akin to TDD,
I'm actually expecting the first couple of deployments to fail. Maybe
you're missing a critical JavaScript library or don't have the same
level of access in the test environment as you do locally. These initial
failures are valuable in detecting any hidden or forgotten
dependencies. Ensuring that your product's deployment process is solid
as early as possible will reduce or eliminate the number of nasty
surprises as you approach the end of development. The last thing you
want to do is to earn the dubious 'Works On My Machine' certification shortly before the release.
Whether
your deployment process is manual or based around continuous delivery
get your application out there as soon as possible. Whether you adhere
to Agile or work in Waterfall, don't wait until the last moment to test
your release deployment.
Originally posted on LinkedIn.
Monday, August 25, 2014
Monday, May 5, 2014
New developer? Start with the deliverables.
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.
Subscribe to:
Posts (Atom)
