AWS OpsWorks is a configuration management service that provides managed instances of Chef and Puppet.
N/A
TeamCity
Score 7.4 out of 10
N/A
TeamCity is a continuous integration server from Czeck company JetBrains.
N/A
Pricing
AWS OpsWorks
TeamCity
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
AWS OpsWorks
TeamCity
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
AWS OpsWorks
TeamCity
Considered Both Products
AWS OpsWorks
Verified User
Anonymous
Chose AWS OpsWorks
Opsworks will become EOL soon and we have been using the recommended Systems Manager solution recently which offers a lot more flexibility in terms of orchestration technology (ie. higher Chef versions) and easier to integrate with even more AWS services.
We first got up and running with OpsWorks about 6~7 years ago, at a time when many of its competitors were far more limited. At the time it made sense as the logical tool to go with and getting up and running on the AWS infrastructure was beneficial for the scale we were …
OpsWorks isn't really a direct competitor to Terraform/Cloudformation, but it does allow you to do some of the more simple things on offer quite quickly and effectively. Opsworks was used for this reason, along with existing internal knowledge of Chef. Along with some of the …
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 …
Since we were already making use of other JetBrains offerings, TeamCity had a leg up on the competition due to the ease of integration with these tools. With that said, TeamCity's feature set stacks up well with the competition. Jenkins definitely has some nice features, but …
This application is easy to install and deploy at site than most of the similar solutions in market. Easy user interface is one of the reason it can be installed. However each software have its good points and bad points. Study your organizations case and then only choose …
I would also like to compare TeamCity against Snap-Ci as well as Concourse. We chose TeamCity over all of these tools because of its ability to be set up easily against a restricting corporate firewall. We needed to integrate unit tests, integration tests, pushes to production, …
TeamCity competes against the TFS build, Visual Studio Team services and Jenkins the open source workhorse. The reason for selecting TeamCity was because it was found to be a great fit for all the diverse projects on a spectrum of technologies we have which the TFS Build …
Cloud Services Practice Manager and Principal Architect
Chose TeamCity
TeamCity is a great on-premise Continuous Integration tool. Visual Studio Team Services (VSTS) is a hosted SAAS application in Microsoft's Cloud. VSTS is a Source Code Repository, Build and Release System, and Agile Project Management Platform - whereas TeamCity is a Build and …
I like the quality of Jetbrains products. TeamCity is well supported and regularly updated by Jetbrains. They have an active support forum and most questions are answered quickly.
TeamCity is very extendable and has been able to handle everything we've been required to do.
We've only ever really used TeamCity as a CI platform. Running tests on these CI clusters is worlds more efficient and just plain easier than having to run individual tests on your local machine. You just hit one button here, versus either writing some run script or even worse …
TeamCity is the best combination of price and full features. It has a good web UI and doesn't need a lot of manual configuration files, but it still is incredibly extensible and can do just about any build or release task you set it at. If it can't do it, the odds are it has a …
Jenkins and Team Foundation Server (TFS) are both strong products. Compared to Jenkins, TeamCity is much more mature and polished. Though Jenkins is open-source/free, the cost of TeamCity is a drop in the bucket compared to the total cost of even one project we're using it …
AWS Opsworks is good for linking AWS services and setting up and maintaining webservers using Chef. However, it will become EOL soon so we would not recommend starting new projects using it and instead go for the recommended Systems Manager setup
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
The interface is quite intuitive and allows you to discover and easily find what you want to do and what other features are within OpsWorks.
Chef integration is pretty seamless and there are a good set of options and operating systems to choose from
It makes things like auto scaling set up, either via load or time, more straight forward and intuitive than what you'd typically see via the EC2 console
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.
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.
Unless you pay for a pricey support package getting support on OpsWorks will be pretty slow. Documentation is also relatively limited and sometimes hard to follow when compared to competitors. Generally, we've been able to get the answers we need from OpsWorks support when we run into problems but don't expect rapid responses.
OpsWorks isn't really a direct competitor to Terraform/Cloudformation, but it does allow you to do some of the more simple things on offer quite quickly and effectively. Opsworks was used for this reason, along with existing internal knowledge of Chef. Along with some of the other services on offer from AWS, it is good to use as a stepping stone along the way when building your systems - or perhaps it would be entirely suitable for a fairly simple project.
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.
OpsWorks allowed us to access the AWS infrastructure with a considerably lower time investment than we would have otherwise needed when we first implemented it.
Since we've been running with OpsWorks we've experienced very little downtime and it's required relatively little maintenance.
The main downside of using OpsWorks for us is that it has locked us into a very specific infrastructure that doesn't have the flexibility of many of the newer infrastructure management tools, this may lead to a painful migration down the road. We also run a risk of long outage if it ever does introduce breaking changes as the skillset needed to work with the OpsWorks tooling is very specific not widely available in our company.
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.