3

I read about CI/CD, loved it, but I'm having trouble with the details as everything I read was high level.

Some authors seemed to suggest that there couldn't be any failing commits on the repository (or master branch?), so a programmer that is delivering bad code would be stopped and he wouldn't be able to create a big mess. He would be forced into fixing his code so that the tests pass.

Others mentioned that the trigger would be the pull requests, not the commits. I haven't used pull requests a lot to be honest, and besides aren't they something external to git? They aren't part of git AFAIK, but part of services like github, bitbucket, etc., so I wasn't sure if I should bind my workflow to something like that.

Any thoughts on this will help me greatly. Please also mention which tools you are using, eg: Jenkins, Buildbot, etc. None of the tools I have tried were very friendly IMO. The docs and examples were lacking or tied to certain technologies like java, or services like github. I even considered building my own, it shouldn't be too hard to get the basic functionality. Right?

  • You didn't find Jenkins friendly? That's the first time I've heard someone say that. <shrug> – Bryan Oakley May 6 '14 at 21:44
  • @BryanOakley I've had lots of problems with its web interface. The errors weren't clear, I had to refresh the page to be able to see the credentials I just added to the form (losing all the info I just entered in other fields), a tiny and blank popup appeared many times, etc. I would much rather have no GUI at all and use a clean command-line API, than a shitty GUI. – ChocoDeveloper May 6 '14 at 21:57
  • The gui is crap, its true. But you get over that quickly once you realize how powerful it is. Its got a lot of depth to it that we've utilized extensively. – Michael Durrant May 6 '14 at 22:27
6

The short answer is: Do what works for your team.

In a perfect continuous deployment scenario you might have this as a workflow:

  • each commit (in a centralized system) or push/pull to a particular branch (in a decentralized system) would trigger the code to be built.
  • If the build succeeds, that should trigger unit tests.
  • If that succeeds, that should trigger an integration test.
  • If the integration tests pass, that should trigger a deploy to a staging system
  • If the deploy works, that should trigger automated acceptance tests
  • If the acceptance tests pass, that should trigger a deployment to production
  • If that works, it should trigger some automated smoke tests.

Now, in the real world, rarely does it work that way. Every team has their own workflow. You might have a couple of phases for QA and staging, or you may deploy straight from a build machine to production. You might require a manual test phase, or you might require performance tests, etc.

There is no perfect answer, except whatever makes the most sense to you and your team. Trigger on every commit if you want, or only trigger on a push to a particular branch. Which is best for you depends on what is important to you and what sort of test coverage you have. It also depends on how long your tests take to run. You don't want to have to wait half an hour before committing a line of code.

All that being said, as a general rule you shouldn't move your code to where it affects others until it has been tested.

1

We use ruby, rails, rspec and jenkins with the following workflow:

  • developer develops in a branch, writes unit tests and also runs the full test suite.
  • developer pushes branch
  • qa pulls branch, merges branch into master, resolves any merge conflicts and runs tests
  • if the tests pass, qa pushes updated master
  • git push of master triggers ci (jenkins) to run the full suite.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.