Skip to content

Home

Jump to bottom
Arjan Einbu edited this page Jun 5, 2017 · 3 revisions

Welcome to the arjanpoc wiki!

This project is a Proof Of Concept for Scriptabuild, the scripted build system.

Scriptabuild lets you use any kind of scripting you like to script your build process, be it a Bash, Powershell or windows batch file, or you even write it in Python, JavaScript (via Node, npm, gulp etc) or C# (perhaps via ScriptCS) or any other language code or combination of these.

Below are notes for points I think will fit nicely in the future README file of the project.

  1. Just as our code isn't static, our build process isn't static either. When we're changing code, we will often also change aspects of the build process, like the tools to run and their configuration, the structure of our project and outputs, frameworks to include etc.

    We manage changes in our code with a source control system, so why do we accept that our build process configuration to exist in only a single version in a typical CI tool. I believe we should place the description for the build process in a source control system too. This will help us ensure that a rebuild of an older version of our code will be done with the correct settings of that time, and take away some of the concerns of changing the build process.

  2. Why do so many CI tools still take the approach to fill in couple of text boxes, check a few boxes etc. as the approach for configuring our build process? There are a couple of problems with this:

    • It limits us in to whatever functionality the creators of the CI tool foresaw we would need. We as developers are good at writing code and scripts, and when doing that we're limited only by our knowledge or lack of creativity.

      (I know we can create add-ons/plugins in many CI tools. To do that we need to learn yet another framework to create our plugin which will work only in that CI tool.)

    • It makes it hard for us to reuse a build process on another project, since we now need to copy/paste from several textboxes, checkboxes etc.

      (I know many tools offer to copy a configuration when starting a new project, but this can often only be done at project startup. Make a complex build process change over multiple projects becomes very hard. Copying a larges piece of text from a script, or even an entire file would be easier.)

  3. CI tools that are tied to run on a server makes it harder to improve, fix or debug our build process, since we need to run the process at a server. When doing so, we may interfere with the workflow of other developers doing their job of developing and checking in code.

    With scripts each developer is able to run the scripts locally, both for testing that the scripts are working, but perhaps also to verify that they won't break the build process when checking in code.

Clone this wiki locally