4 ms·
Ask HN: How is your code/build/test/deploy flow organized?
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,..
We use jenkins for builds, but how can we easily organize "build and deploy version X into production" things (assuming that we do not have db migration overhead)
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.
- brudgers 11y agoTo 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 11y agoWe 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
- drakonka 11y agoWe 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.