One Binary - Revision history

Kevlin at 10:32, 16 August 2009

Kevlin — Sun, 16 Aug 2009 10:32:04 GMT

←Older revision		Revision as of 10:32, 16 August 2009
Line 3:		Line 3:
	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.		I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

-	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This could mean, for example, keeping them in the component container, in a known file, or in the path.	+	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This could mean, for example, keeping them in the component container, in a known file, or in the path.

-	If your team ~~does have~~ either a code-mangling build or stores all the target settings with the code, ~~then it~~ suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse~~, that the~~ team knows what to do but can't ~~prioritise~~ the effort to make the change.	+	If your team either has a code-mangling build or stores all the target settings with the code, that suggests that no one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or it could be worse: The team knows what to do but can't prioritize the effort to make the change.

-	Of course, there are exceptions~~, you~~ might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally, but start as soon as possible.	+	Of course, there are exceptions: You might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally — but start as soon as possible.

-	And one more thing: Keep the environment information versioned too. There's nothing worse than breaking an environment configuration and not being able to figure out what changed. The environmental information should be versioned separately from the code, since they'll change at different rates and for different reasons. Some teams use distributed version control systems for this (such as bazaar and git), since they make it easier to push changes made on production environments (as inevitably happens) back to the repository.	+	And one more thing: Keep the environment information versioned too. There's nothing worse than breaking an environment configuration and not being able to figure out what changed. The environmental information should be versioned separately from the code, since they'll change at different rates and for different reasons. Some teams use distributed version control systems for this (such as bazaar and git), since they make it easier to push changes made in production environments — as inevitably happens — back to the repository.

	By [[Steve Freeman]]		By [[Steve Freeman]]

Sf105 at 09:43, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:43:07 GMT

←Older revision		Revision as of 09:43, 16 August 2009
Line 5:		Line 5:
	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This could mean, for example, keeping them in the component container, in a known file, or in the path.		The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This could mean, for example, keeping them in the component container, in a known file, or in the path.

-	If your team does have either a code-mangling build or stores all the target settings with the code, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the ~~changes~~.	+	If your team does have either a code-mangling build or stores all the target settings with the code, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the change.

	Of course, there are exceptions, you might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally, but start as soon as possible.		Of course, there are exceptions, you might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally, but start as soon as possible.

Sf105 at 09:42, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:42:30 GMT

←Older revision		Revision as of 09:42, 16 August 2009
Line 3:		Line 3:
	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.		I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

-	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This ~~might~~ mean keeping them in the component container, in a known file, or in the path.	+	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This could mean, for example, keeping them in the component container, in a known file, or in the path.

	If your team does have either a code-mangling build or stores all the target settings with the code, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the changes.		If your team does have either a code-mangling build or stores all the target settings with the code, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the changes.

Sf105 at 09:41, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:41:38 GMT

←Older revision		Revision as of 09:41, 16 August 2009
Line 1:		Line 1:
-	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always ~~seems to make~~ thing more complicated than they should be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.	+	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always makes thing more complicated than they should be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.

	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.		I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

Sf105 at 09:41, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:41:19 GMT

←Older revision		Revision as of 09:41, 16 August 2009
Line 1:		Line 1:
-	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than ~~necessary~~, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.	+	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than they should be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.

	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.		I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

Sf105 at 09:40, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:40:51 GMT

←Older revision		Revision as of 09:40, 16 August 2009
Line 1:		Line 1:
-	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than ~~they need be~~, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.	+	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than necessary, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.

	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.		I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

Sf105 at 09:40, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:40:18 GMT

←Older revision		Revision as of 09:40, 16 August 2009
Line 3:		Line 3:
	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.		I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

-	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.''	+	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.'' Hold environment-specific details ''in the environment''. This might mean keeping them in the component container, in a known file, or in the path.

-	~~Hold environment-specific details ''in the environment''; this might mean in the component container settings, a known file, or the path.~~ If your team does have a code-mangling build, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the changes. Of course, there are exceptions, you might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications.	+	If your team does have either a code-mangling build or stores all the target settings with the code, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the changes.

-	And one more thing: Keep the environment information versioned too. ~~Some teams like~~ to ~~keep the settings in the same repository as~~ the code~~; some like a~~ different ~~repository~~. ~~There are advantages~~ to ~~both~~.	+	Of course, there are exceptions, you might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally, but start as soon as possible.
		+
		+	And one more thing: Keep the environment information versioned too. There's nothing worse than breaking an environment configuration and not being able to figure out what changed. The environmental information should be versioned separately from the code, since they'll change at different rates and for different reasons. Some teams use distributed version control systems for this (such as bazaar and git), since they make it easier to push changes made on production environments (as inevitably happens) back to the repository.

	By [[Steve Freeman]]		By [[Steve Freeman]]

Sf105 at 09:26, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:26:35 GMT

←Older revision		Revision as of 09:26, 16 August 2009
Line 5:		Line 5:
	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.''		The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.''

-	Hold environment-specific details ''in the environment''; this might mean in the component container settings, a known file, or the path. Of course there are exceptions, ~~say where~~ you~~'re~~ building for targets that have significantly different resource constraints, but ~~they don~~'t apply to the majority of us who are writing "database to screen and back again" applications. If you do have a code-mangling build, then it suggests that either the team hasn't thought through its design enough to figure out which parts of the system move where or, worse, that the team has but cannot find the time to make the changes.	+	Hold environment-specific details ''in the environment''; this might mean in the component container settings, a known file, or the path. If your team does have a code-mangling build, then it suggests that no-one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or, it could be worse, that the team knows what to do but can't prioritise the effort to make the changes. Of course, there are exceptions, you might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications.

	And one more thing: Keep the environment information versioned too. Some teams like to keep the settings in the same repository as the code; some like a different repository. There are advantages to both.		And one more thing: Keep the environment information versioned too. Some teams like to keep the settings in the same repository as the code; some like a different repository. There are advantages to both.

Sf105 at 09:18, 16 August 2009

Sf105 — Sun, 16 Aug 2009 09:18:39 GMT

←Older revision		Revision as of 09:18, 16 August 2009
Line 1:		Line 1:
-	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than they need be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake. I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.	+	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than they need be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake.
		+
		+	I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.''		The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.''

Sf105 at 12:14, 15 August 2009

Sf105 — Sat, 15 Aug 2009 12:14:03 GMT

←Older revision		Revision as of 12:14, 15 August 2009
Line 1:		Line 1:
-	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make ~~things much~~ more complicated than they need be, and introduces a risk that the team may not have consistent versions on each ~~box~~. At a minimum it involves building multiple, near-identical copies of the software which then ~~have~~ to be deployed to the right ~~places~~. It means more moving parts than necessary, which means more opportunities to make a mistake. I~~'ve~~ worked on a team where every change had to be checked in for a full build cycle, ~~which meant that our~~ testers were left waiting whenever they needed a minor ~~setting~~ adjustment. I~~'ve~~ worked on a team where the system administrators insisted on rebuilding from scratch for production, which meant that we had no proof that the version in production was the one that had been through testing. And so on.	+	I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always seems to make thing more complicated than they need be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake. I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on.

-	The rule is simple. Build a single binary that you can identify and promote through all the stages in the release pipeline. Hold environment-specific details ''in the environment'' in~~, for example,~~ the component container settings, a known file, or the path. Of course there are exceptions, say where you're building for targets that have significantly different resource constraints, but they don't apply to the majority of us who are writing "database to screen and back again" applications. If you do have a code-mangling build, then it suggests that either the team hasn't thought through its design enough to figure out which parts of the system move where or, worse, that the team has but cannot find the time to make the changes.	+	The rule is simple: ''Build a single binary that you can identify and promote through all the stages in the release pipeline.''
		+
		+	Hold environment-specific details ''in the environment''; this might mean in the component container settings, a known file, or the path. Of course there are exceptions, say where you're building for targets that have significantly different resource constraints, but they don't apply to the majority of us who are writing "database to screen and back again" applications. If you do have a code-mangling build, then it suggests that either the team hasn't thought through its design enough to figure out which parts of the system move where or, worse, that the team has but cannot find the time to make the changes.

	And one more thing: Keep the environment information versioned too. Some teams like to keep the settings in the same repository as the code; some like a different repository. There are advantages to both.		And one more thing: Keep the environment information versioned too. Some teams like to keep the settings in the same repository as the code; some like a different repository. There are advantages to both.