How to start CI

From CitconWiki
Revision as of 11:43, 3 October 2015 by Glook (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

What does it really mean? How do you know that you are really doing it? If we are all wondering that, how do we learn? :-)

We start by going around the room and talk about what we have learned about CI.

J: I don't know how to do it though I seem to be responsible for it. When I don't have to run tests on my local machine, I will know that I am well on my way.

P: Embedded software, no web deployments, and I've learned that I am not ready to scale my CI.

S: Just been a sponge this week. Not really doing CI other than getting some unit testing. As far as knowing when we're there... When we are doing deployments, running tests, and pushes to production in a few days.

I: Atlassian. Continuous integration with Bamboo. Interested in how to start. Does have some stories.

Worked with a guy once with no CI experience, dragging his feet, felt it was extra work. Days later, glad they were doing it and thought it was wonderful. It seems like people who are doing CI never go back after getting past a certain hump.

He once joined a team that had done CI before and each were certified scrum masters. We still had to learn what CI meant to each person.

G: New to all of this.

Summary of the last couple days: CI starts with regular checkins that triggers a constant build. After the build is complete, automated tests are run to varying degrees. The automated tests do different things but can include sanity of production value.

One question is 'What can you take out to make the minimum easier?"

Historically, the experts on the subject of CI have always favored automated tests. Web seems to not allow for automated tests.

Shooting for automated tests as a baseline is good.

We need faster feedback. Having code written without feedback requires adaptation.

A member talks about bringing CI in house and then the hardware died. No one yelled loud enough to get it brought back.

Do you think code reviews are integral to CI? Group consensus is yes.

Code review can serve multiple purposes but it is very special to Continuous Integration. The whole span of continuous is that you are not afraid to turn something into automation then you can keep getting the next job faster. These continuos processes lead to more automation.

What sort of things would you be automating? Depends on code review. If the errors are curly brace positions then we should pick a coding standard and then use a tool that will enforce it.

You should have clear requirements if you are implementing CI.