Use of CI and CD

[Jay Vaughan]

> I've been looking a lot into Continuous Integration and Continuous Deployment to improve our methodologies lately.
> We have been using a sort of "CI Light" with a build server (TeamCity) to deploy to test and then a file-sync tool (SynkBack) to promote it to prod for the last couple of years but I'm looking into taking it a step further.
> Anyone have any thoughts/tips/anything to share regarding this? :-)

I've been using this technique since the 80's, so I'm quite amused by the solidification of the whole technique into an 'accepted method'.  The key principle is, always check in buildable code, isolate your work branches from the main branch with strict task-based branch names, and always test in the target environment instead of some developer environment.

To that end, it doesn't really matter what tools you use on the back end .. what matters is your own discipline about how you apply this technique to improve software quality. 

In my current project, its all MOAI (see http://getmoai.com/) and this is a good example for how and why CI/CD are valuable.  With MOAI, you write non-native code in Lua, using the MOAI SDK, and then you run it everywhere that the MOAI host is natively available - iOS/Android/Win/Linux/&etc.  So for development, we (I have now a small team locally working on projects with me) develop on our native hosts - OSX and Linux, using an editor. We test our development process with local hosts - simple "Build" in the editor and our app runs on our dev machines.  Whenever a developer starts a new task, they create a named branch for that task, and they don't check into the main integration build server until the branch is 'done' - that is, no incomplete work gets checked in, just the branch itself.

When a branch is merged - the task is done and the branch is merged - the build server gets the code (we have our own build-server wired up with git hooks) and immediately builds a package for all target native environments with the code.  These packages are made available to our customers for testing, and they understand that these are test branches, but they integrate with their production flow in a way that it won't disturb their real work if something goes awry (a few users in the group are given tester rights and get their builds from the new branches).

At each sprint, we list the branches checked in, and sign off on the branches that are working in the test-production environment.  These then get rolled out to all users at that point.  It works very well - we catch bugs very early (we're good development-testers anyway) and our workflow never gets interrupted by having to do a massive deployment of months of work at the same time - the integrated rollouts and features creeping into the main branch after each sprint has sort of gotten us all in good synchronicity with each other.




;
--
Jay Vaughan