At Ritter Insurance Marketing we value our peers and other organizations in the overall software community. We believe in the power of c...OSS
Software development is a funny thing. As I develop my skills, I begin to form an idea of what’s right and wrong, what’s up and down. Thi...elasticsearch
At Ritter Insurance Marketing we have a number of repositories, each with separate continuous integration builds. This is a base setup f....NET Cake AppVeyor
In the whirlwind that is modern web development, I thought it would be a great idea to revisit one of the fundamental parts that make the...HTML Web
Picture a scenario where you want to page a large dataset and your LINQ statement has several Include-calls. The first few pages load fai....NET SQL Server LINQ
Setting up a local server comes in many flavours today. My goto was the Apache vhost.conf/hosts combo, now to load something quickly - Gu...gulp
[Hacktoberfest 2017][hacktoberfest] is upon us and now is a great opportunity to contribute to open source and the community as a whole. ...OSS
TL;DR Using ExecuteReader against SQL Server with a query using for xml or for json causes data to be chunked. A single call to ExecuteR....NET .NET Core 2.0 JSON XML SQL Server
At Ritter Insurance Marketing, we continue to invest heavily in Web APIs primarily built on top of ASP.NET Web API 2. To supplement our A...asp.net WebAPI REST
If you CSS, you’re familiar with the browser -prefix. Chrome and Safari have -webkit, -moz for Firefox/Mozilla, and -ms for Edge. As brow...css
We decided not to use Material Design (#reasons) while re-developing our core application suite, although i really miss MD’s micro-intera...UI Sass Semantic UI
Sometimes it’s useful to ensure a project works with multiple versions of runtimes. In the following example, multiple versions of Node.j...AppVeyor
Update October 17, 2017 This doesn’t work with environment deployments, as this needs to run after the deployment has completed. See htt...AppVeyor
https://xkcd.com/1597/ While I generally don’t do that, here’s what I currently do: Setting up a repository locally Using Stuntman as...GitHub
On our team TeamCity server we build repositories by default using
build.cmd in the repository root. This has a few advantages.
One advantage is being able to run what TeamCity runs locally. It isn’t perfect – your machine can still be different from the TeamCity build agent. But, it allows running the same commands consistently. This can greatly improve the experience of debugging works on my machine issues.
Another advantage is keeping any complex build setup in the repository. Files in repositories are versioned and follow the familiar pattern of submitting changes via pull requests.
Here’s a simple
build.cmd to get started (this one is useful for Node.js, but can be adapted for your needs!):
@echo Off pushd %~dp0 setlocal :Build call npm install call npm test if %ERRORLEVEL% neq 0 goto BuildFail goto BuildSuccess :BuildFail echo. echo *** BUILD FAILED *** goto End :BuildSuccess echo. echo *** BUILD SUCCEEDED *** goto End :End echo. popd exit /B %ERRORLEVEL%
In this case, the build will run
call npm install and
call npm test in order. You can modify these steps as necessary.
When creating a new build configuration for a project, a template can have
build.cmd usage baked in. This consistency makes it faster and easier to setup a build configuration for new projects.
Team members can assume
build.cmd will be ran for each TeamCity build. Having a consistent build script makes setting up new projects in TeamCity faster and easier, since executing
build.cmd is included as part of a template. And, if a pull request fails to build unexpectedly a quick
git clean -xdf and
./build.cmd can run what the build agent ran!
build.cmd enhances our team development experience by providing consistency.
build.cmd works locally and fails on a TeamCity build agent, this post won’t help you! :-)