Comments on: A tip for continuous integration shops http://www.cmdln.org/2009/07/04/a-tip-for-continuous-integration-shops/ a system administrators mutterings Sun, 28 Feb 2010 09:28:06 -0600 http://wordpress.org/?v=2.9.2 hourly 1 By: Julian Simpson http://www.cmdln.org/2009/07/04/a-tip-for-continuous-integration-shops/comment-page-1/#comment-888 Julian Simpson Tue, 07 Jul 2009 07:38:29 +0000 http://www.cmdln.org/?p=359#comment-888 Nice post. Just thought I'd add to the comment from Mr Hericus (hello again!) that CI looks set to become more and more central to the release process in organisations. A lot of shops now generate tags from the CI processs and use them to track artifacts through to deployment. There's a couple of CI servers now that allow you to invoke all your deploy steps from the server itself. Which could be good with the right security and process. Nice post. Just thought I’d add to the comment from Mr Hericus (hello again!) that CI looks set to become more and more central to the release process in organisations. A lot of shops now generate tags from the CI processs and use them to track artifacts through to deployment. There’s a couple of CI servers now that allow you to invoke all your deploy steps from the server itself. Which could be good with the right security and process.

]]> By: Mr. Hericus http://www.cmdln.org/2009/07/04/a-tip-for-continuous-integration-shops/comment-page-1/#comment-887 Mr. Hericus Sun, 05 Jul 2009 21:38:51 +0000 http://www.cmdln.org/?p=359#comment-887 Continuous Integration is actually getting more and more play outside of the "pure dev" team. It has and continues to be applied to teams of documentation writers, QA test developers, and to other IT areas successfully. As you state, it's the practice of ensuring that whatever is committed to the shared repository plays well with everything else already there and doesn't introduce any automatically detectable regressions in the code/docs/tests/etc. I agree with your assessment, you have to have a plan when putting CI into place. For the small team/small project it's easy to get up and running quickly. But for larger projects, everything should be defined in the CI system. It becomes the repository of knowledge for how the whole system is put together. Thanks for the post! Mr. Hericus Continuous Integration is actually getting more and more play outside of the “pure dev” team. It has and continues to be applied to teams of documentation writers, QA test developers, and to other IT areas successfully.

As you state, it’s the practice of ensuring that whatever is committed to the shared repository plays well with everything else already there and doesn’t introduce any automatically detectable regressions in the code/docs/tests/etc.

I agree with your assessment, you have to have a plan when putting CI into place. For the small team/small project it’s easy to get up and running quickly. But for larger projects, everything should be defined in the CI system. It becomes the repository of knowledge for how the whole system is put together.

Thanks for the post!

Mr. Hericus

]]> By: Nick Anderson http://www.cmdln.org/2009/07/04/a-tip-for-continuous-integration-shops/comment-page-1/#comment-886 Nick Anderson Sun, 05 Jul 2009 16:45:43 +0000 http://www.cmdln.org/?p=359#comment-886 I should clarify I am _not_ a developer either. :) So the main thing is that upon each check-in a build is performed. Source code is compiled (if needed), unit tests are run, system tests are run. The idea is you can catch breakage right away. You try to keep "bad" commits from entering the repo by placing importance on the fact that _any_ revision of the main repository should successfully build. For dynamic languages a build could include running unit tests in the code, pushing the code to a staging server, running your fixtures and system tests. So really there is no change for your typical CVS/SVN you just add the build server to the mix. It monitors your repos for changes and upon change it kicks off a build. You then get trends of your breakage etc ... I think it is also useful to show the importance of automation. Its easy to not have automatic deployment but that possible variation by not being automated is dangerous for troubleshooting later. I should clarify I am _not_ a developer either. :)

So the main thing is that upon each check-in a build is performed. Source code is compiled (if needed), unit tests are run, system tests are run. The idea is you can catch breakage right away. You try to keep “bad” commits from entering the repo by placing importance on the fact that _any_ revision of the main repository should successfully build. For dynamic languages a build could include running unit tests in the code, pushing the code to a staging server, running your fixtures and system tests. So really there is no change for your typical CVS/SVN you just add the build server to the mix. It monitors your repos for changes and upon change it kicks off a build. You then get trends of your breakage etc … I think it is also useful to show the importance of automation. Its easy to not have automatic deployment but that possible variation by not being automated is dangerous for troubleshooting later.

]]> By: Matt Simmons http://www.cmdln.org/2009/07/04/a-tip-for-continuous-integration-shops/comment-page-1/#comment-885 Matt Simmons Sun, 05 Jul 2009 16:31:46 +0000 http://www.cmdln.org/?p=359#comment-885 Ah, cool. Not being a developer, I was unfamiliar with the concept of continuous integration. I looked it up (http://www.martinfowler.com/articles/continuousIntegration.html) and it seems useful to the dev teams. What are some of the differences in the underlying infrastructure between a normal CVS/SVN environment and a continuous integration setup? Ah, cool. Not being a developer, I was unfamiliar with the concept of continuous integration. I looked it up (http://www.martinfowler.com/articles/continuousIntegration.html) and it seems useful to the dev teams.

What are some of the differences in the underlying infrastructure between a normal CVS/SVN environment and a continuous integration setup?

]]>