The programming tools series of articles (which, I know, I promised I had already finished) relied heavily on the version control system at its heart.
Today I want to talk about a new feature of versioning: Magic Files
Imagine, I check into the version control system my source code (or a gif), I want the facility to say to the VCS "now give me the compiled code" (or "now give me a jpeg version of the gif"). The VCS - not me - should know how to generate the file I'm asking for. Because there should be rules which tell the VCS how to generate the file
Now, because we can make a rule that any such process should be side-affect free, once the VCS has generate the file, it can keep a copy of it, at least until one of the files that were used in generating it has changed. And there is nothing to say that the VCS has to wait for someone to ask for the file before it generates it - if it sees free processor time, the VCS can spawn compilation.
We can take this further: why not just check out your test results file: that would run every test and tell you how it did. And running an individual test [by looking at the individual test results log] would just check out the files it needed to run - which means only the files needed to perform a test would be compiled - leading to the optimal code-compile-test loop.
In short, I'm talking about merging the version control system and make.
Its a different world - and one which probably requires far more storage (and a few extra VCS features such as a 'regenerate' option to regenerate a file which for some reason went awry) - but one which feels to me more inherently usable, and which provides us with more records of exactly what has and hasn't been run.
Showing posts with label version control. Show all posts
Showing posts with label version control. Show all posts
Thursday, 13 May 2010
Thursday, 29 April 2010
Programming Tools: Bugtracking
My final set of requests for a development environment involve the bug tracking system.
The initial observation that I wish to make is that bugs relate to a particular version of code. And that bugs stay with code until they are fixed. This means that bugs are related to the version control system. For any branch of the code, you should find exactly which set of bugs it has, and which bugs remain open. Closing bugs tends to relate to a particular point in a version control system: either "This is the fix for the code" or "This is the point where I verified that the bug no longer exists". When you split a branch, you take the bugs from that point in time - and when you merge a branch back into the main tree - or pick up the changes from one branch into another, you should pick up the changes to the bug database too.
In an ideal system, when you check out a branch onto a local machine, you should also be able to check out a copy of the bug tracking system... which you can make changes to - changes which will be applied when you merge back later. This allows you a full dev environment when away from the corporate network.
Bugs are also related to tests. Tests should be able to generate bugs... these bugs are probably along the lines of "Test xyz fails", providing links to an overnight test failure. Bugs should also be able to say "This test will identify this bug" so that you can get the test system to help verify when a bug has gone.
Bugs form trees (or rather directed acyclic networks), in a similar way to a version control system. For example the test system might generate the bug "Test xyz fails". I might take this bug and want to split it into two bugs "On windows test xzy fails because of foo" "On Linux test xyz fails because of something else". If I were to then notice that I already have a bug about windows failures due to foo, I should be able to merge that bug with it.
Bug entry needs to be easy. Really easy. When a test fails, I need to be able to add a few notes to it and WHAM! thats the bug added. Bugs are a place to store knowledge, and to allow me to find things that are outstanding.
Bugs also need to be integrated with email. I need to be able to send people questions, directly relating to the bug (so that the question, and the response, are stored in the bug). Bugs really are a chat system. This is not a bad thing.
Finally, Bug tracking and todo lists are tightly integrated. So much so, that most developers I know use bug tracking as their todo list. So when I send another developer a question - that needs to show up in their todo list - as an uncompleted part of a bug. And users need to be able to add their own private bugs, and import their emails into bugs to let them keep track of their own tasks.
I've talked about bug tracking for non-IT businesses elsewhere. And this bug tracker needs to support all of that.
The initial observation that I wish to make is that bugs relate to a particular version of code. And that bugs stay with code until they are fixed. This means that bugs are related to the version control system. For any branch of the code, you should find exactly which set of bugs it has, and which bugs remain open. Closing bugs tends to relate to a particular point in a version control system: either "This is the fix for the code" or "This is the point where I verified that the bug no longer exists". When you split a branch, you take the bugs from that point in time - and when you merge a branch back into the main tree - or pick up the changes from one branch into another, you should pick up the changes to the bug database too.
In an ideal system, when you check out a branch onto a local machine, you should also be able to check out a copy of the bug tracking system... which you can make changes to - changes which will be applied when you merge back later. This allows you a full dev environment when away from the corporate network.
Bugs are also related to tests. Tests should be able to generate bugs... these bugs are probably along the lines of "Test xyz fails", providing links to an overnight test failure. Bugs should also be able to say "This test will identify this bug" so that you can get the test system to help verify when a bug has gone.
Bugs form trees (or rather directed acyclic networks), in a similar way to a version control system. For example the test system might generate the bug "Test xyz fails". I might take this bug and want to split it into two bugs "On windows test xzy fails because of foo" "On Linux test xyz fails because of something else". If I were to then notice that I already have a bug about windows failures due to foo, I should be able to merge that bug with it.
Bug entry needs to be easy. Really easy. When a test fails, I need to be able to add a few notes to it and WHAM! thats the bug added. Bugs are a place to store knowledge, and to allow me to find things that are outstanding.
Bugs also need to be integrated with email. I need to be able to send people questions, directly relating to the bug (so that the question, and the response, are stored in the bug). Bugs really are a chat system. This is not a bad thing.
Finally, Bug tracking and todo lists are tightly integrated. So much so, that most developers I know use bug tracking as their todo list. So when I send another developer a question - that needs to show up in their todo list - as an uncompleted part of a bug. And users need to be able to add their own private bugs, and import their emails into bugs to let them keep track of their own tasks.
I've talked about bug tracking for non-IT businesses elsewhere. And this bug tracker needs to support all of that.
Monday, 19 April 2010
Programming Tools: The Build Farm
In my first essay on programming tools I suggested that you take some code, press a button and it builds.
What I didn't talk about was how it builds.
Firstly, it doesn't build on your local machine (it could, if you install the right tools, but that's an unnecessary addition. If you're working locally, you just use your version control system back to the online system to build...). Instead of local builds we have a build farm - a set of one or more machines which include all the tools for building for one or more particular environments. When you hit build, your code is shunted off to the first available machine that can build for the platform you require. The build is performed, and the results are returned.
Actually - its even better. Because this is always happening in behind the scenes, as you type. Whenever it gets a chance a new build of your code is scheduled... so usually when you press the build button the results are instantly available.
And by results I mean build errors and warnings. I mean binaries. I mean all outputs one would usually see from a build. Of course, you probably won't care about the binaries because for most of your development time you'll be using a test farm to cope with these. The errors are the important thing - and they'll be checked into the appropriate point in the version control system so that they are always instantly available
In order to make such a system work, each machine in the build farm will need to have a working build environment installed (its probably best to do this with a VM image, so that making clones is easy). They will also need a daemon process to control the build. Its probably best to think of this as being the build tool - the equivalent of make.
The build tool will advertise itself on the network (using zero-conf or rendezvous or whatever), along with advertising the systems it is capable of building for. Any machine with a tool put on the network will automatically be available to build
I've spent a lot of time thinking about what the ideal replacement for make would be like, but the long and the short of it is, the characteristics of the build system tool won't matter so long as it is possible to only need to rebuild those files which have changed... it could rely heavily on the vcs here, after all, it will know from the vcs exactly which files are different from the last build.
I do think, however, that directory structure is probably not a desirable thing to have. Rather, it should be possible to put files into groups either explicitly, or by smart groups (just as you have smart folders in itunes). A file can be in many groups. When a build tool needs an arbitrary structure, it should be possible to generate it on the fly by moving (groups of )files to the correct locations. This gets over the issues with - say - Microsoft's driver build environment, which only allows two levels of directory structure, and helps where the directory structures need to be different on different platforms. It also helps with version control: at the moment version control systems have to try to emulate every filing system their files may run on, so that permissions and so forth can be replicated correctly. Moving files around is a pain. With this system, everything can fall into build system metadata, and we can provide our own security features (such as restricting changes different code areas to different program groups) if we need them. Of course, build system metadata is stored in a file in version control - so if a file is merged or permissions need to be changed, those changes are tracked like everything else - transparently.
The end result of this complexity is simplicity. Once a build has been set up, it will 'just work' for everybody. If you suddenly need to build for another platform, its just a simple choice of a new platform to see if it works. You can test every platform quickly and easily without searching for appropriate machines and solving 101 build problems.
And because a build daemon is externally controllable - it is no effort at all to use it (and maybe a particular 'gold' machine) for scheduling nightly builds. Or rolling test builds of the code integration branch.
Programmers life is simpler. Builds are easier. Testing is easier. And everyones' lives can be made faster and easier still just by throwing on new hardware. Its a win for everybody.
What I didn't talk about was how it builds.
Firstly, it doesn't build on your local machine (it could, if you install the right tools, but that's an unnecessary addition. If you're working locally, you just use your version control system back to the online system to build...). Instead of local builds we have a build farm - a set of one or more machines which include all the tools for building for one or more particular environments. When you hit build, your code is shunted off to the first available machine that can build for the platform you require. The build is performed, and the results are returned.
Actually - its even better. Because this is always happening in behind the scenes, as you type. Whenever it gets a chance a new build of your code is scheduled... so usually when you press the build button the results are instantly available.
And by results I mean build errors and warnings. I mean binaries. I mean all outputs one would usually see from a build. Of course, you probably won't care about the binaries because for most of your development time you'll be using a test farm to cope with these. The errors are the important thing - and they'll be checked into the appropriate point in the version control system so that they are always instantly available
In order to make such a system work, each machine in the build farm will need to have a working build environment installed (its probably best to do this with a VM image, so that making clones is easy). They will also need a daemon process to control the build. Its probably best to think of this as being the build tool - the equivalent of make.
The build tool will advertise itself on the network (using zero-conf or rendezvous or whatever), along with advertising the systems it is capable of building for. Any machine with a tool put on the network will automatically be available to build
I've spent a lot of time thinking about what the ideal replacement for make would be like, but the long and the short of it is, the characteristics of the build system tool won't matter so long as it is possible to only need to rebuild those files which have changed... it could rely heavily on the vcs here, after all, it will know from the vcs exactly which files are different from the last build.
I do think, however, that directory structure is probably not a desirable thing to have. Rather, it should be possible to put files into groups either explicitly, or by smart groups (just as you have smart folders in itunes). A file can be in many groups. When a build tool needs an arbitrary structure, it should be possible to generate it on the fly by moving (groups of )files to the correct locations. This gets over the issues with - say - Microsoft's driver build environment, which only allows two levels of directory structure, and helps where the directory structures need to be different on different platforms. It also helps with version control: at the moment version control systems have to try to emulate every filing system their files may run on, so that permissions and so forth can be replicated correctly. Moving files around is a pain. With this system, everything can fall into build system metadata, and we can provide our own security features (such as restricting changes different code areas to different program groups) if we need them. Of course, build system metadata is stored in a file in version control - so if a file is merged or permissions need to be changed, those changes are tracked like everything else - transparently.
The end result of this complexity is simplicity. Once a build has been set up, it will 'just work' for everybody. If you suddenly need to build for another platform, its just a simple choice of a new platform to see if it works. You can test every platform quickly and easily without searching for appropriate machines and solving 101 build problems.
And because a build daemon is externally controllable - it is no effort at all to use it (and maybe a particular 'gold' machine) for scheduling nightly builds. Or rolling test builds of the code integration branch.
Programmers life is simpler. Builds are easier. Testing is easier. And everyones' lives can be made faster and easier still just by throwing on new hardware. Its a win for everybody.
Thursday, 1 April 2010
Programing Tools: New Version
Once we've asserted that your programming tools should run in a web browser, we can start deciding what back end functionality it needs. The most important is version control.
Now, there is nothing new about version control, so I won't go into it here... but I want to point out that my last article just assumed version control: I suggested you could go to the code and start to edit it. Of course, what I meant was
You log into the system
You find the code you want to edit
You pick a button marked new workspace
You enter that workspace and modify the code.
The workspace is a version controlled branch. There will be options to update your workspace, and merge your workspace into other workspaces.
But all of this is transparent - for the developer its just how you work. Each time you save, thats a revision (auto saves may or may not be revisions... I suggest not). You can tag revisions with comments when you reach points where that is useful.
One final clever bit: the version control system is one of the standard ones... or compatible with one of the standard ones. A distributed VCS, naturally - git or mercurial (I have almost no git experience, so assume I'm talking about mercurial here). So, if a developer wants to work outside of the online toolchain, they can simply download a brnach to their own machine and work from there. When they are done (or just want to compile - they can push their branch back to their online workspace, and take advantage of the compilation and test features provided.
But the compilation and test features are other articles...
Now, there is nothing new about version control, so I won't go into it here... but I want to point out that my last article just assumed version control: I suggested you could go to the code and start to edit it. Of course, what I meant was
You log into the system
You find the code you want to edit
You pick a button marked new workspace
You enter that workspace and modify the code.
The workspace is a version controlled branch. There will be options to update your workspace, and merge your workspace into other workspaces.
But all of this is transparent - for the developer its just how you work. Each time you save, thats a revision (auto saves may or may not be revisions... I suggest not). You can tag revisions with comments when you reach points where that is useful.
One final clever bit: the version control system is one of the standard ones... or compatible with one of the standard ones. A distributed VCS, naturally - git or mercurial (I have almost no git experience, so assume I'm talking about mercurial here). So, if a developer wants to work outside of the online toolchain, they can simply download a brnach to their own machine and work from there. When they are done (or just want to compile - they can push their branch back to their online workspace, and take advantage of the compilation and test features provided.
But the compilation and test features are other articles...
Subscribe to:
Posts (Atom)