Search

Sebastian Gnagnarella

Lot of things, but deep inside just a Geek,,, well not so deep…

Category

Management

Continuos Integration as a Martial Art

Few months ago I read a great article that was suggesting a journey for CI comparing it with the different steps in learning Karate.

Unfortunately the article was in Spanish so I couldn’t share it right away, but I decided to take some minutes this morning and come up with a rough translation for y’all.

Original Article from Martin Salias: http://www.codeandbeyond.org/2016/05/el-kyu-dan-de-la-integracion-continua.html

* In case you are a Karate guru on the team ,  the belt colors may be out of order or just wrong 🙂 *

White Belt

  • Install Team City or Jenkins
  • Every team should learn how to configure their own projects
  • Each commit has to automatically compile
  • Projects in RED are not allowed

Yellow Belt

  • Start with tests and run them with every commit
  • Again, projects in RED are not allowed, use this opportunity to learn what the others are doing and stabilize the tests

Orange Belt

  • Start with TDD and ATDD, increase the number of tests too
  • Start measuring code coverage and enforcing it (at least 1% for each new class)
  • Start increasing the code coverage limit, if the code coverage is not satisfied the project should go in RED
  • Every time a bug is reported in test or prod, write the test to demonstrate the issue first, and then fix it

Green Belt

  • Start executing static code analyzer and have the build server reporting on them
  • Focus on the main issues reported, and once fixed, start enforcing code quality (project goes into RED if it is not passing)

Blue Belt

  • Start versioning code together with database migrations, configurations and libraries
  • Make the build server compile, run all the tests and validations and generate a new testing environment from scratch

Brown Belt

  • Work with dev ops and web ops to validate and adopt environment deployment scripts and processes
  • Have the build server create a test environment from scratch with every commit and also an incremental one (upgrade/update)
  • Automatic rollbacks in the incremental environment using scripts

Red Belt

  • Every time there is a commit and all tests and validations pass, generate a package that can be deployed to production with the click of a button.
  • Start working on hot-deploy , non user impacting , deployment automation

Black Belt

  • Every time there is a commit, goes to production without interrupting the service
Advertisements

Does the CIO make that call or do the architects make the decision with the CIO’s input?

Few weeks ago, a good college of mine asked for my opinion on this matter. I’ve realized I haven’t written anything in a while, and you know… :).

Here is my answer :


In my mind one of the CIO’s responsibilities is to define the high level technology strategy and although he/she may not be fully equipped to decide on a particular technology stack – lack of domain knowledge or just not enough time to research all the options available – she should collaborate with the architects and feel confortable with the decision (also stand behind it as there is no room for pointing fingers later!).

There are plenty of consideration when settling on a technology stack that may not be part of the architect purview:

  • Technology Market Adoption
  • Potential developers available in the market
  • Company long term road map and strategy
  • Financial factors
  • Future strategic alliances

Also there are plenty of considerations that may escape the CIO’s knowledge:

  • Frameworks available
  • Technology Performance for a certain task
  • etc

 

It is also the CIO’s job to help the team broaden their spectrum and “force” them to do research. Let’s say you are working with a Java architect – although I rather architects to be technology agnostic – if that person is reluctant to using other technologies, he will try to solve the problem with Java (you know, if the only tool you know is a hammer….).

Summing up, the CIO/CTO should define the global strategy considering technology and non-technology factors and foster internal research. Architects should come back with a variety of options and healthy debate should happen. The CIO will be ultimately responsible for the decision in front of the executive team and the board. This is a really important choice to be taken by just one person, and for some reason you have hired architects.

Blog at WordPress.com.

Up ↑