Progress Chef vs. TeamCity

Chef is a very nice tool for establishing and maintaining a consistent configuration across a range of servers. In addition, Automate allows the continued monitoring and maintenance of servers so they don't drift from established standards. Overall, it deals very well with complex systems. Chef is slightly less applicable for a micro-services approach where the servers are replicated from a simple and known starting point.

Incentivized

TeamCity is well suited for an organization using continuous integration, meaning you release code to production often, and an agile project management system. There are free versions available for small teams and enterprise versions available for large teams with many different builds. TeamCity is probably overkill for basic e-commerce or blog website builds that do not require much development after the initial launch

Incentivized

• Chef is very easy to learn. Written in ruby, Chef code is high enough level for non-ruby coders to get a general idea of what the script is doing.
• Chef can be a one stop shop for writing code, testing infrastructure, and deployment of applications.
• The Chef support team is very helpful in their auto manager support as well as active support in their Slack channels from development engineers & architects.

Incentivized

• Fully customizable build process. Each step of the build process can be parameterized and customized to address specific needs of particular applications. This allowed us to easily convert from a custom VM-based environment to our current Docker-based environment.
• Manages large numbers of build agents seamlessly. This allows us to run multiple builds on many different applications in a most efficient manner.
• Build steps can be managed in an arbitrary manner, allowing some parts of the process to proceed in parallel while restricting others to depend on completion of all relevant steps.

Incentivized

• One main concern with Chef is the maintainability of Chef master.
• The Chef-client should be installed on every node we want to do any automation.
• It is mostly Ruby and there's a learning curve. Need to understand the fundamentals of Chef very throughly to play around with attributes, templates etc etc.
• The Chef-client agent needs to be run on the nodes frequently to update the details of it state to master. And also to index the nodes based on tags.

Incentivized

• It is not plug and play thing
• Need more specific configurations for smaller projects as well
• Online help is less available
• Basic implementation is easy but I think feature add on can be complex as it involve some language knowledge as well.

Incentivized

The suite of tools is very powerful. The ability to create custom modules allows for unlimited potential for managing all aspects of a system. However, there is pretty significant learning curve with the toolset. It currently takes approx 3-4 months for new engineers to feel comfortable with our implementation

Incentivized

It loads quick enough for basically all our systems. Because we have this for local dev environments, speed isn't really a big issue here. Yes, depending on the system, sometimes it does take a relatively long time, but it's not an issue for me. One thing that is annoying is that if I want to make a small change to a cookbook and re-run the Chef client, I can't just make the change in the cache and run it. I have to do the whole process of updating the server.

Incentivized

TeamCity runs really well, even when sharing a small instance with other applications. The user interface adequately conveys important information without being overly bloated, and it is snappy. There isn't any significant overhead to build agents or unit test runners that we have measured.

Incentivized

Support for Chef is easily available for fee or through the open source community as most the issues you will face will have been addressed through the Chef developer community forums. The documentation for Chef is moderate to great and easily readable.

Incentivized

Chef is the more developer-oriented of the three main tools in this space. It has a steeper learning curve as a result but it allows you to do more. Puppet seems to be more geared towards automated the management of the operating system. Ansible is an excellent tool but requires you to allow SSH connectivity into all of your instances.

Incentivized

Jenkins relies on being open source as the primary driver for its success. This low cost is a huge factor for many companies, both small and large. The professional, free tier of TeamCity offers a huge amount of growth before ever needing to pay anything. I personally also find the user experience of TeamCity to be much better, both from a look and feel, as well as from an out-of-the-box feature set perspective. The big selling feature of ADO is its native integration with Azure. TeamCity integrates very well with out-of-the-box .NET support and greatly simplifies our use of another diverse tooling outside of the Microsoft ecosystem.

Incentivized

• We can deploy tens to hundreds of servers in a small amount of time.
• We can grow our infrastructure very quickly with limited resources adjusting to customer demand as soon as the need arises.
• We are able to automate many of the mundane tasks that used to occupy the time of our engineers allowing us to focus on more critical tasks.

Incentivized

• TeamCity was a key contributor to our organization's adoption of Agile.
• TeamCity made it possible to KILL "It works on my laptop" conversations with Developers. If it does not compile in TeamCity - the project is not deployable. TeamCity's easy to use interface made it possible to quickly adopt a "Deploy Only from TeamCity" policy, further ensuring TeamCity Builds were the gold-standard for well-configured source code.

Incentivized