Hot on the heels of the first release of TeamCitySharp, a new update has been released for the project to nuget. There were 2 major additions to the project both contributed via pull requests on Github.
Introduction of Build Locator
This makes the protocol for obtaining build information easier as we use the locator in the url rather than trying to build a query string manually. Previously we built a query string as follows:
http://myserver.com/httpAuth/app/rest/buildTypes/id:bt437/builds?status=SUCCESS
This would get the successful builds for build config id 437. This has now been replaced by the following query string:
http://myserver.com/httpAuth/app/rest/builds?locator=buildType:id:bt437,status:SUCCESS
Thanks must go to Simon Bartlett for this addition to the codebase. The existing methods will work in this way as the code behind the public methods has been changed to us the build locator pattern. Therefore you can still call the method:
Behind the scenes TeamCitySharp does the following call:
New Sample Build Monitor
There is now a new project included in the source code. This project is a sample implementation of a build monitor using TeamCitySharp based on MVC3 and Knockout.js. Thanks to Barry Mooring for contributing this sample to the project.
In order to use the build monitor you just need to go to the settings file and add the TeamCity url, username and password.
This gives a look and feel as follows:
You can download the source from Github or via nuget (install-package TeamCitySharp). Please feel free to leave feedback about what you feel it is lacking or what you don’t like about the project. This library will only be able to get better through help from users.
I have heard people talking for a while on the TeamCity pricing strategy and thought I’d write a post to start to get some opinions on what you think it should be changed to.
TeamCity users are very lucky that we have a free, without restriction, version of the software to use. It comes with 20 build configurations and 3 build agents. Unfortunately, people still do not find this adequate for their needs. The enterprise version has unlimited build configurations and 3 build agents and is approx. £1600. So the question here is:
What do you think the pricing model of TeamCity should be?
If we can get good feedback, we can give this to Jetbrains in order to let them see what their customers feel they need. This post, or discussion, does not in any way guarantee that the pricing of the tool will change.
I have heard the following suggestions:
- Make the enterprise version come with 5 build agents
- Have a version between Free and Enterprise that allows like 70 build configurations
- Give the ability to buy package extras e.g. 20 build configurations for $500 etc.
What do you think? Comments required please!
TeamCitySharp (TCS) is a simple .net wrapper that will let you interact with a TeamCity server providing you have a login for that system. TeamCity has a REST API but this wrapper will help simplify the calls that that API and deserialize the response for the server into POCOs for you.
In order to get a list of projects on a TeamCity server you would make the request to the following URL:
http://<serverurl>/httpAuth/app/rest/projects
In order to interact with this, you could use EasyHTTP or HTTP WebRequest. You would set up a connection, specify a content type, give user credentials and then get a response back that you can use. TeamCitySharp has taken care of this for you. The corresponding code to make the same code using TeamCitySharp would be as follows:
There are a number of methods available that will let you get projects, build status’, build types, users, agents, user groups and server information. The project cannot be used to create projects or build types. This is due to the absence of the appropriate calls on the TeamCity REST API. A full list of functionality of the TeamCitySharp API calls can be found in the documentation.
I have created a TeamCitySharp nuget package and you can install that from nuget command line using the comment:
install-package TeamCitySharp
This is very much an early version of the project in order to get user feedback. If you do try it then please do let me know what you don’t like about it and what you feel it would benefit from. Thanks really must go to Hadi Hariri for the idea after I saw YouTrackSharp.
Please feel free to fork the project and send any requests back you feel the project would benefit from. The project is distributed under the MIT license so please adhere to this when using it.
“Until your pretty code is in production, making money, or doing whatever it does, you've just wasted your time” - Chris Read whilst at London CI.
In my opinion, this quote really sums up software development. Process and red tape are becoming an obstacle to more and more developers from doing what they are paid to do – create software.
I attended a talk by Kendall Miller whilst at DDDScotland entitled “Creating your own software company: A survival guide”. I am a huge supporter of continuous delivery and have attended many sessions but this session was extremely useful to me. It was really the first time that the reasoning and importance of continuous delivery for developers really hit home with me. I knew the benefits and drawbacks but hearing someone actually demonstrate their experience really helped me. The most important thing I learned in this session was that you have got to get your software out early, this is particularly important when you are starting up a software company. Shipping software early will not only give you a source of much needed income, but can provide potentially useful feedback that can help shape the project before too much investment, both in terms of development time and money, is wasted. This goes hand in hand with the opening quote of this blog post.
I am a huge fan of clean, SOLID, DRY code and I cannot emphasise enough about why developers should write code in this fashion. I do understand that I may be giving a mixed message here. Is it possible to create software in a clean, SOLID and DRY way and in a fast time? Could we be sacrificing quality for delivery? In my opinion, this is simply not the case. There are some fantastic guide lines laid down by Robert ‘unclebob’ Martin in his book, Clean Code. These guide lines do not take extra time to implement – they are baked in to how we write the code. As developers they should be second nature to us. If they aren’t then you should address this as soon as you can.
Fast delivery can, however, affect architecture. Architecture is one of those areas of development that really does demonstrate a lot of ways to do achieve a single task. For example there are many different frameworks, tools, code layout etc. and these are another area to be concerned with. You can implement a solution to a problem that is clean & efficient but that may not prove to be the best architecture. You could continue to work on this solution and refactor it to the nth degree until you come up with an architecture that you like. You may feel that you have used your development time wisely to improve your solution, when in actual fact, what you may have done is to waste your development resources refactoring when other solutions may be available to you.
I would argue that release fast, fail fast is a good way to develop. Get the code out there, let some decent A/B testing give feedback on its fit for purpose and let that shape the architecture. I understand this may be easier for start-up based systems as their customer base can initially be small. But I do not think it is only targeted towards them. Lets look at Google Chrome or Firefox as an example of this philosophy in practice. Changes to Chrome and Firefox are happening on a regular basis now. This means the companies can create a new piece of functionality, release it to users and collect feedback and know that feedback is targeted towards the last small release. This means they are letting the user feedback help drive the system. Firefox takes a lot of grief about how resource hungry it is. Releasing smaller code changes more often will help them see if they are addressing the issue.
Releasing a solution early can also bring problems of it’s own. There are some companies out there that are of the opinion – if it has shipped and it works then why should we spend any more money on code improvements. This falls into the argument about Technical Debt which I will not cover in this post.
In summary, I believe software should be delivered in small, continual chunks. This helps create an efficient delivery mechanism that will give us a chance to collect useful feedback in a much more structured and continual way. We can use this feedback to deliver software that is better suited for its purpose and become better at what we are paid to do!