
Ask HN: How is your code/build/test/deploy flow organized? - tuyguntn
We use git for source code management, but thinking about which method of versioning is easier and more scalable in long-run. we can put tag for each release, but when we need to fix older version say v0.1, we cannot easily checkout, fix then commit. Instead we are going to use branch for major versions, v0.1, v1.0, v1.1, v2.0 and etc, tags for minor versions inside each branch, v0.1.1, v0.1.2,..<p>We use jenkins for builds, but how can we easily organize &quot;build and deploy version X into production&quot; things (assuming that we do not have db migration overhead)<p>Would be awesome if you can give some details about pros and cons of your current flow, or maybe best practice for creating such flow.
======
drakonka
We currently use a custom CI system. We produce dozens of builds per day in
various forms. A "build" to us has different definitions depending on who it
is targeted to. They include things like:

* Just building binaries/code

* A data build

* A build that content creators work with (built binaries synced to PC, matching data synced via P4 which they then build locally)

* A full files/package/disc build with included data and binaries

Coders and content creators have different branches to keep some isolation
between the two and avoid them impacting each other too much. New binaries are
built with every submission to source control as a verification step on the
coder branch, but most are only deployed once an hour. Some sets of binaries
are deployed at all times, those that are required to run our automated tests
on each CL.

The content creator branch always work with a pre-approved set of binaries.
When they submit new data it goes through a verification step where all data
is built and autotests run, then that data CL shows up as "good" for them - so
they know that data is safe for everyone to sync and work with.

We create full packages for QA to test a few times throughout the day.

The general build steps in a CL on the code branch goes through are:

* Build code

* Build data

* Run autotests

* Once an hour deploy new binaries to sync

The general build steps a CL on the content branch goes through are:

* Build data (no need to build code here as we just sync the pre-approved binaries)

* Run autotests

* Deploy approved build (or mark a CL as "good")

That's the general gist of it, anyway.

------
brudgers
To me, one workflow - either branches or tags - would seem simpler and make
describing and tooling the process simpler. Again, to me, since git is
primarily about branching, I'd probably go with branching. Then again,
branches with little or no reason to exist beyond semantics wouldn't bother me
as much as it might bother someone else.

Good luck.

------
buildops
We use IncrediBuild - it speeds up our development and CI. C++ dev on Visual
Studio with some teams running C# and CI into Jenkins. The C# team has more
automated unit tests with MSTest, which is where they shine

