4 ms·

I mostly work with java, so the build server is doing a clean compilation, to ensure the code word outside my dev environment. Pulling in known versions of depe

I mostly work with java, so the build server is doing a clean compilation, to ensure the code word outside my dev environment. Pulling in known versions of dependencies, some packaging, unit and integration tests etc. Mostly using Maven. Whilst some of that is somewhat specific to java, I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. And I'd still want to run at least some integration tests, even for the simplest project. And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway. Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place.

StavrosK 11y ago
> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there. > And I'd still want to run at least some integration tests, even for the simplest project. Integration tests run on the dev or CI server, in my case. > And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway. The code servers aren't in the internal network, in my case. They're already internet-facing, since I need to pull from them. > Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place. In my case, if my code isn't on the server, the server doesn't run. There's no need to set up .htaccess, since the HTTP server doesn't serve anything off the filesystem.
- NickNameNick 11y ago
  >> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. >In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there. The problem is not that dev dependencies exist, the problem is that they might be undeclared or unrecorded. I have imagemagic on my dev machine, but if it isn't installed as part of the server setup script, then it won't be on the production server. The tests might run fine on a dev server that happens to have imagemagic on it, but fail in production. >Integration tests run on the dev If you run your integration tests in your dev environment, you might not catch some on the fly configuration changes or utility installations - undeclared dependencies.
  - StavrosK 11y ago
    I'm using "dev environment" and "dev server" distinctly. The dev environment is whatever I have on my computer, the dev server is a server that mirrors production. If there's a dependency on your dev environment that isn't on production, you'll catch it when you deploy to one of the dev servers. Same with the integration tests.

StavrosK 11y ago

> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there. > And I'd still want to run at least some integration tests, even for the simplest project. Integration tests run on the dev or CI server, in my case. > And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway. The code servers aren't in the internal network, in my case. They're already internet-facing, since I need to pull from them. > Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place. In my case, if my code isn't on the server, the server doesn't run. There's no need to set up .htaccess, since the HTTP server doesn't serve anything off the filesystem.

NickNameNick 11y ago
>> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. >In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there. The problem is not that dev dependencies exist, the problem is that they might be undeclared or unrecorded. I have imagemagic on my dev machine, but if it isn't installed as part of the server setup script, then it won't be on the production server. The tests might run fine on a dev server that happens to have imagemagic on it, but fail in production. >Integration tests run on the dev If you run your integration tests in your dev environment, you might not catch some on the fly configuration changes or utility installations - undeclared dependencies.
- StavrosK 11y ago
  I'm using "dev environment" and "dev server" distinctly. The dev environment is whatever I have on my computer, the dev server is a server that mirrors production. If there's a dependency on your dev environment that isn't on production, you'll catch it when you deploy to one of the dev servers. Same with the integration tests.