New answers tagged

0

In a past job we had a similar setup (DTAP) though we did not use SVN (we used Perforce) it would have been easily ported since both are or the same VCS family. We had a development branch where all development occurred. Since branching is fairly costly in P4, same holds true for SVN we did not use sprint branches, only when a feature, or user story, or ...


1

I'd separate test stability from test duration, they matter in different manners. Test stability is critical if the test is executed rarely and there aren't enough datapoints to actually measure the stability. Checken and egg problem. But if enough execution datapoints exists to allow an estimation of the test stability then it can be incorporated in the ...


0

Couples things to keep in mind: Your team needs a set of standards to follow You need to get management on board with the idea of clean code and strive for improved code practices. Test test test! Always test before you check in. Although I do agree it is ok to break build, that's a rare and I mean extremely rare occasion that would be acceptable. If this ...


1

Visibility will help you out. All team members need to know that there is an active problem that they should fix. Email notifications are useful, but if a developer is busy and does not react to it immediately, he will probably forget about it and the email will end up in a huge notifications pile. You can try using tools like Catlight or BuildNotify. They ...


8

Typically you have multiple pipelines - you run "quick n dirty" unit tests as devs commit changes. When they say they're ready to merge their changes into a testing branch, you run a more "slow n steady" integration tests (and any other analysis tools you like). If these pass, you merge the testing branch onto some QA branch where you can generate deliveries ...


4

Go for it - Jenkins is an awesome choice for CI server, is easy to set up and work with. It doesn't take much server resource either. What CI gives you is a computerised 'build person' who can take your code from a repository and build it without your assistance. If you quit or get hit by a bus, this means that your code will still be usable without ...


-1

That's a quite interesting scenario. Normally, CI is to solve problems related to multiple people working together on the same projects - that's what the "integration" part means. The whole point of it is detecting conflicting changes that can break the build. If you are each working alone on separate projects, you won't see much benefit from CI per se. ...


4

I think it's an excellent mechanism to use. You're going to be able to confirm that your own builds (if no-one else's) will work in an isolated, reproducible environment. It'll check if you forget to commit work in your SCM system, and that the builds and tests all work in a controlled environment, independent of your personal environment. If your tests take ...


0

Here is the extract from continuous delivery author: Jez Humble Writes as: I am currently writing a blog post on this topic. The short answer is this: The best way to review code is through pair programming It's a bad idea to gate merge to mainline - by creating a separate branch, for example - on a formal review process. This inhibits continuous ...


2

Test as much as possible before deployment Deployment isn't cheap. Even if the deployment is fully automated and pushed automatically from the commit it still takes time to deploy, it prevents any use of the development environment while deploying and if you deploy a broken application the development environment is stuck until things get fixed. This ...



Top 50 recent answers are included