Free and open source DevOps tools can help DevOps teams streamline their development processes and speed development cycles, when carefully selected to meet the team’s criteria. This can go beyond cost limitations as many free DevOps tools can provide an equal level of functionality compared to some paid tools. Others offer less functionality than comparable paid competitors. When extra bells and whistles aren’t required, opting for more basic, free tools when they suffice can help keep development costs manageable.
Just as in all aspects of information technology tools, “free” is a relative term that can mean many things. Some tools are free for so many users, for a specific time period, for specific build parameters, and other identifiers before they reach a cost structure threshold. Some are free and open source without qualifiers, but there are other costs to consider, such as the time you’d invest in mastering tools that come with a steep learning curve.
One of the biggest perks of using free and open source DevOps tools is that many have large communities of users and contributors who constantly improve the tools as time goes on. The size of that community, the change cycles, things that the tool may never be able to do, and lesser-known capabilities will all be potential factors that can make a free DevOps tool more, or less valuable. No matter what tools you add to your DevOps toolkit, security should be a top priority. With Threat Stack’s Cloud Security Platform®, you can easily integrate security into your DevOps world. Threat Stack’s Cloud Security Platform helps you detect security incidents and achieve continuous cloud compliance, without disrupting your workflow.
The bottom line is that DevOps teams must know where they are going and how they want to get there to truly evaluate potential DevOps tools. This list of tips from a wide variety of reputable sources can help developers and teams shape their criteria list by bringing light to different tools and aspects of those tools that should be considered. We’ve split the list into categories based on DevOps tool types to make it easier to navigate and to bring more value to any users:
- General Tips for Evaluating Free DevOps Tools
- Tips for Evaluating Free Testing Tools
- Tips for Evaluating Free Automation Tools
- Tips for Evaluating Free Version Control Tools
- Tips for Evaluating Free Containers and Orchestration Tools
- Tips for Evaluating Free Analytics Tools
- Tips for Evaluating Free Building Tools
- Tips for Evaluating Free Performance Monitoring Tools
- Tips for Evaluating Free Communication Tools
- Tips for Evaluating Free Database Automation Tools
- Tips for Evaluating Free Repository Management Tools
- Tips for Evaluating Free Configuration/Deployment Management Tools
Disclaimer: The resources in this post are not ranked in terms of perceived value or quality of content. Nor do the lists imply an endorsement of any product or service. Our intent is simply to provide you with information that we feel could be helpful as you add to your knowledge of useful DevOps tools.
General Tips for Evaluating Free DevOps Tools
- Free DevOps tool evaluation requires looking at each tool within the context of the entire SDLC and their needed level of integration with other tools and processes.
“To make the transformation less stressful and understand the tools you need, you must understand current processes, procedures, and standards within the entire software delivery lifecycle. Evaluate the tools you’re currently using as well. What source control management system, testing tools, and other technology is integral to your processes? What tools could you consolidate, replace, or eliminate completely?
“By performing a comprehensive audit, you’ll identify commonalities between the groups involved, determine requirements, and develop a common set of objectives that can be used when considering the right tools to bring on board. For example, if your teams use containers, you should look for DevOps tools that support containers.”
– Rebecca Pruess, How to Find the Best DevOps Tools for Your Business, DZone; Twitter: @DZone
- DevOps teams must have a well-defined process for evaluating potential tools before beginning the process to ensure gaining atonable data for making the decision.
“Consistency is critical to any tool evaluation. Do not evaluate one tool by reading the vendor’s website and a couple datasheets, then evaluate another tool by bringing it in-house for a multi-week evaluation. Figure out how you want to score each capability and evaluate each tool consistently. Some capabilities can be evaluated by reading datasheets. Others can be evaluated with a live demo and Q&A. Some capabilities you must see for yourself in your own environment.”
– Jeff Downs, Guest View: Five steps to evaluating and selecting software tools, SDTimes; Twitter: @sdtimes
- Open Source CI/CD tools can make or break a project based on their support community and documentation.
“What makes a strong and growing CI/CD tool solution? Active community message boards for levels of expertise, users sharing knowledge, best practices, lessons learned, and openly sharing ideas. The best support for any tool is excellent documentation that stays up-to-date.”
- Agnostic application integration capabilities across the DevOps pipeline is an important consideration in choosing the right DevOps tools.
“Not all integrations are created equal. Tying your toolset together with individual scripts is breakable and difficult to scale. An application-agnostic automation tool can act as a centralized console to manage your entire environment, connecting to any application that provides an API or web service.”
- Broad integration capability is the standard that any tool must pass to be considered for any DevOps team and project.
“If your DevOps tool makes it hard to work with other tools, it will probably lead to issues and complexity. On the other hand, if your tool integrates with lots of other tools and platforms, it will help you keep things simple.
“That’s because continuous integrations help to ensure that you can easily move data from one tool to another or move your tool from one platform to another. You don’t want an APM tool that works only with one type of public cloud, for example, because you’d then have to adopt a separate tool if you decided to move to a different cloud, thereby bloating your toolset. You also don’t want to have to write custom configurations or integrations in order to share log data from one platform with a tool that was not designed to support that platform.
“The number of integrations offered by DevOps tools varies widely. When selecting a tool, consider how its integrability will influence the simplicity of your overall toolset.”
- Keep in mind that even open source tools have costs that must be considered in tool evaluation.
“Adding a CI/CD tool to your development toolchain will always come at a cost. Even if you have chosen an open-source tool and are running it on your own infrastructure, you will be faced with costs which you need to consider. These include the time needed to setup and support the tool and the loss in productivity as your developers learn the new toolchain. Proprietary and SaaS tools will additionally have costs based on the level of usage. Factors you need to consider before you start looking are:
“How many builds will I be doing? On larger projects, you may end up running builds many times a day. Some vendors may impose limits on this or may charge based on this.
“Do you need to be building concurrently? If you have several development teams, they may all want access to the build toolchain at the same time. This means you may need more infrastructure or more resources from a SaaS vendor.
“How many users do you need? Many vendors will charge you more the more users you have.
“Often you will find that there’s no clear answer as to which solution offers the best value. Not least because you will be trading off the costs of CI/CD against the savings in streamlining your development and release cycle.”
- Tools with intuitive dashboards can save a lot of headaches in terms of information gathering, sharing, and compiling.
“A standout amongst the most distressing parts of shipping software is getting all the change, test, and sending data for an up and coming discharge into one place. The exact opposite thing anybody needs before a release is a long meeting to write about status. This is the place where release dashboards come in. Search for tools with a solitary dashboard coordinated with your code repository and deployment tools. Discover something that gives you full perceivability on branches, fabricates, pull solicitations, and organization notices in one place.”
– How to choose tools for DevOps?, Online IT Guru
- The ideal scenario is to limit the number of tools as much as possible without limiting the effectiveness of the DevOps team to innovate and work efficiently.
“Collaboration and transparency are keys to standardization, and these need to be a part of the process when choosing any standard toolset, said Ian Buchanan, senior developer advocate at Atlassian. When tool standards are set, they might not fit the needs of other teams in the organization – but too many tools can make it harder to share knowledge and use the tools.
“‘The challenge to standardization is striking the right balance between team autonomy and the ability to redirect teams to the highest priority business problems,’ Buchanan said.”
– Christine Parizo, Standardizing DevOps tools requires culture change and careful evaluation, Tech Pro Research; Twitter: @TechProResearch
- While ALM tool evaluations can be based on an established team’s former tool use, a new team will need to take collective knowledge criteria from seasoned team developers and join it with any criteria that can be identified to fill in any gaps.
“In most cases, if you’re looking for an ALM, your teams have already been using a handful of industry tools for quite some time. Determine whether you’re so heavily invested in a services vendor (SAP, Oracle, etc.) that you should prioritize ALM tools that offer pre-built integrations with those services.”
– Ben Aston, 10 ALM Tools To Deliver Better Projects, DPM
- DevOps tool evaluations require a solid cross section of team specialists groups to weigh in on possible choices along with the primary developers to ensure a good fit where different programming languages may be in play for a release cycle.
“When programs are built using a polyglot of different languages, organizations need good DevOps tools to manage that integration.
“The vetting process and the operation of the tool can be done by different people and do not often fall into typical development roles. QA/QE teams could be good administrators of such a tool or, in some organizations, make a good DevOps team. Even the legal department manages it. Everyone contributes to what should be in the library, with most requests coming from developers.
“The other aspect of such a tool is how it fits in a delivery chain. It must integrate with your release automation processes; otherwise, its benefits will not be fully realized. And it should fit into all phases – development, integration and production – not just development.”
– Chris Riley, Choosing the right DevOps tool to tame your polyglot programming, TheServerSide; Twitter: @TSS_dotcom
- Every DevOps tool selection process starts with the understanding that no tool can do everything.
“Looking for a software solution that fully and precisely supports your current way of working is likely to be a fruitless search and it narrows your vision, effectively eliminating the opportunity for change. So, you need a tool that can adapt to the new process you probably haven’t implemented yet and may have not even have devised. The process you implement is unlikely to remain static so, can the tool change with you? Is the tool you are considering configurable? Beware of tools that offer support for any process you like, provided it’s ours!”
– 10 Questions You Should Ask When Choosing a Tool for Requirements Management, Inflectra; Twitter: @inflectra
- Without a firm understanding of how the application lifecycle should be shaped, DevOps teams cannot effectively choose the right tools for creating the best DevOps pipeline.
“Rather than choosing DevOps tools by looking through a laundry list of popular services, you should consider your application lifecycle and approach the decision-making with those specific goals and objections in mind.”
– The Ultimate DevOps Toolkit for the Application Lifecycle, AppDynamics; Twitter: @AppDynamics
- The GitHub Community is a great source for information on CI tools being used by developers.
“If you need a little inspiration for which CI tool might work best, take a look at popular GitHub projects. Many show the status of their integrated CI/CD tools as badges in their README.md. We’ve also analyzed the use of CI tools across more than 50 million repositories in the GitHub community, and found a lot of variety.”
- The more your seasoned team members know about any particular CI tools and the usefulness of their plugins, the easier it is to assess them as part of a narrowed list of potential CI tools.
“It’s preferred when a solution has a varied public store of assorted plugins, usable build steps, which could be open-source or commercially available. It’s important that the team can quickly learn how to use the chosen tool and start developing the product using its benefits. Depending on your team’s expertise level and the programming software they already work with, the range of CI tools can be narrowed down.”
- User history, specific needed functionality, trusted peer opinions, and recognized best-of-breed options are all important means for evaluating and narrowing the list of possible CI tools.
“Before deciding which tool is right for you, look at your projects and what you really need to move them into the 21st century. For example, Zuul is overkill for most projects. Others, such as Spinnaker, are great for testing and delivery, but they’re not meant for integration.
“Before looking at the tools, decide on which functionality you need. There’s no point in investing in Jenkins, which is great at CI, when what you really want is a CD tool for your existing CI system.
“Do you want to self-host or use a cloud-based service? What are your company’s data storage rules? Which fits better in your budget? Keep in mind if you self-host, you need an in-house DevOps team to run it.
“What do others in your field think about these services? Is there already a recognized best-of-breed CI/CD tool in your business? Or, as with Kubernetes, must you face the sad fact that there is “no single best set of tools” for CI/CD. In any case, you need to do a lot of testing to find the right fit for your company.”
Tips for Evaluating Free Testing Tools
- Open source testing tools will have some limitations, and teams must have a clear view of their need to evaluate whether those limitations can be easily overcome or are inconsequential.
“If the functionality of application under test changes frequently or is too complicated, it is difficult to create test automation for all the application features, because every tool has its own limitations.
“If you don’t want to be in such situation, before selecting the test tool, you must analyze the test cases and decide which test cases should be automated and which test cases should not. This is the Automation Feasibility Analysis activity.”
- Robust communication and alerts are vital components to look for when evaluating the best testing tools.
“Look for tools that automatically apply your tests to development branches and give you the option to push to master when branch builds are successful. Along with that, you can get real-time alerts in your team’s chat tool with a simple integration.”
- Visibility, scalability, and integration are equal considerations when evaluating test management tools.
“The right test management tool for DevOps is one that enables agile teams to work collaboratively in the different areas described above – automated build, automated testing and automated provisioning of infrastructure for deployment – in order to speed up the release of high-quality software. Doing that effectively means it should be able to integrate with other project management, issue tracking and automation tools in your DevOps toolchain.
“It also should have live reporting features since you need to maintain real-time visibility into the products in your DevOps pipeline. This is important so that information about bugs, inefficiencies or other issues can be shared and acted on in real-time. If you’re a small or medium-sized business (SMB), it also helps to choose a tool that can scale to fit the needs of an enterprise or very large enterprise team.”
– Sanjay Zalavadia, How to choose the best test management tool for DevOps, Zephyr; Twitter: @yourzephyr
- With AI and ML becoming important capabilities in DevOps, teams should consider whether a given test automation tool has the potential for its integration.
“Test automation tools is a crucial component in the DevOps toolchain. The current test automation trends have increased in applying artificial intelligence and machine learning (AI/ML) to offer advanced capabilities for test optimization, intelligent test generation, execution, and reporting. It will be worthwhile to understand which tools are best poised to take advantage of these trends.”
– Brian Anderson Best Automation Testing Tools for 2020 (Top 10 reviews), Medium; Twitter: @Medium
- The more a team understands the data it needs, the better their position for evaluating potential test automation tools.
“Ultimately, choosing the right test solution is going to mean paring down to the test results, test cases, and test scripts that you need. Automated tools make it easier to complete specific tasks. It is up to your organization to first model the data it has and identify the results that it needs before it can determine which automated testing tool will yield the best results.
“Many companies may need to use multiple automated products, with some being used for user experience, others being used for data validation. Others are used as an all-purpose repetitive testing tool.”
- Evaluating testing tools should be based on a deep understanding of your own DevOp processes and needs for where automation will be effective.
“Maintaining the quality of an application by delivering a bug-free product is crucial for the success of any project. Automated testing can help improve the quality of a project and increase scope & depth of the tests. For this, get a deep understanding of your project requirements such as project type (web/desktop/mobile), scope of the project, and existing team’s strength on code language before you start the process. There is no such tool that is good or bad, but the ROI of any tool relies on the need, i.e., what precisely does one need to automate and what amount of test cases needs automation?”
– Faiz Shaikh, 4 Simple Steps to Select the Right Test Automation tool for your Project, Saviant; Twitter: @tweetsaviant
- There are several key benchmarks that teams should use in evaluating potential open source test automation tools.
“The rationale and advantages behind your choice of open-source test automation tools can be related to a few key benchmarks:
- Ease of script development and execution (supports agile processes and short iterations)
- Cross team collaboration capabilities (Both QA and Dev can easily use the same tools)
- Match app platform with test development language (ObjectiveC/Swift for iOS, Java for Android)
- No platform capabilities gap around testing (support for the latest OS features)
- Support for real devices as well as emulators/simulators
- Fully integrated tools within IDEs”
– Selecting the Best Open Source Automated Testing Tool for You, Perfecto; Twitter: @perfectomobile
- The right test management system will leave no loose ends for test parameters that cannot be tracked as part of a unified view in real time.
“It is very important for the testers to able to trace back all their work in a centralized test management system. A bi-directional traceability between test artifacts and the associated requirements and defects increase the efficiency of measuring quality of a project. It also allows organizations to track the coverage of both Requirements and Test Cases, failing which may lead to missing information, loss of productivity and fall in quality.”
- Implementing multiple application security testing tools for different aspects of the testing process in the application lifecycle will improve security, but only if they are applied incrementally to give the team time to adjust and monitor.
“Fortunately, there are a lot of free open-source AST tools, particularly SAST, DAST and SCA. It is a good idea to test your use of AST tools with open-source products before selecting a commercial vendor.
“There are many types of tools available to perform automated application security testing. In keeping with the spirit of the defense in depth security adage, the more tools you run the more likely you are to reduce the weaknesses in your applications. It is costly and time consuming, however, to introduce tools into a development environment. We therefore recommend starting with one tool, becoming proficient with it, and then adding tools as time and resources allow.”
– Thomas Scanlon, Decision-Making Factors for Selecting Application Security Testing Tools, Software Engineering Institute CMU; Twitter: @SEInews
Tips for Evaluating Free Automation Tools
- Creating a sandbox environment is one of the best ways to evaluate automation servers.
“In order to make a good decision, a solid approach would be to freely evaluate the tools and how they integrate with your software development products. To properly evaluate each tool, we recommend using Docker repositories to deploy a sandbox environment easily.”
– Ofer Velich, Battle of the Automation Servers: Jenkins vs. Bamboo vs. TeamCity, logz.io; Twitter: @logzio
- Understanding your goals and work processes may reveal that more than one infrastructure automation tool is the ideal answer when vetting possible tools.
“Every infrastructure automation tool has its strengths, weaknesses, and learning curves. In choosing a tool, you’ll want to find the one that best matches the needs of your project and the needs of your teams. Cloud-vendor built tools may provide the easiest way to get the ball rolling as you start your cloud migration, especially if a ‘one-stop shop’ is what you’re looking for.
“That said, tools like Puppet, Chef, and Ansible have built tremendous reputations with DevOps practitioners managing infrastructures in all kinds of cloud environments, and their integrations prove it. But be sure to do your homework because some of the related tools may have exactly what you need. In fact, in many cases, you may find that the best of approach is to combine two or more of these tools.”
– Frederic Paul, The Best Tools for Cloud Infrastructure Automation, New Relic; Twitter: @newrelic
Tips for Evaluating Free Version Control Tools
- Extensive communication capabilities are vital to the best choice in version control systems.
“Using a browser-based version-control platform opens version control to a wider audience than just software developers, which in turn helps you to emphasize the importance of version control as a key DevOps practice. By choosing a version-control tool with discussion capabilities and making it available to a wide audience, you can enable rich communication between teams and groups within your organization.”
Tips for Evaluating Free Containers and Orchestration Tools
- Network connectivity that enables code transparency for dependent services is a vital attribute of a container orchestration tool.
“CNI Networking: The ability to have trivial network connectivity between my services is important. I do not want the developers spending time on special purpose code for finding dependent services. Docker Swarm and Kubernetes, you are both still in the running.”
– Michael Douglass, How to choose the right container orchestration and how to deploy it, FreeCodeCamp; Twitter: @freeCodeCamp
- Container management tool choices are solely dependent on the user knowing how they intend to use them before they evaluate them.
“There are five critical decision points that you must consider when evaluating prospective container management software. Ask yourself: What do you need from a container strategy?
- A basic container platform;
- A basic container system with orchestration capabilities included;
- Public cloud tools;
- Exceptional security container software with basic orchestration; or
- Complex layers of resource abstraction and orchestration.”
– Choose the right container deployment strategy and software, TechTarget; Twitter: @TechTarget
- Containerization tool choices are dependent on the team’s prospective use of different cloud models.
“If you are in the ‘look first at public cloud tools’ category, that means you expect to do most of your container deployment in the public cloud rather than in an owned data center. The first question to ask is whether you expect to be a multi-cloud user or to eventually add containers to your data center. If the answer is no to both of these, then you should plan to get all your container support from the cloud provider. If your answer is yes to both of these, then you should plan to do container orchestration via Kubernetes and use Docker for broad public cloud compatibility.”
– Tom Nolle, Assess and choose the right container management system, TechTarget Buyer’s Guide; Twitter: @TechTarget
Tips for Evaluating Free Analytics Tools
- Product analytics tools will have a major impact on future projects and even other DevOps tools selection.
“Look for a [product analytics] solution that enables you to streamline post mortems and post mortem analysis for the purpose of prioritizing action items regarding what needs to be fixed. You’ll want to measure the success of a service relative to business goals and customer experience metrics, with tools that help you understand product usage and customer feedback. All of these will feed into the next sprint so that you can accurately plan and prioritize both system and feature improvements – for even better product, and happier customers.”
- Two-way communication paths and platform integration with users can be an important aspect to analytics tool choices.
“The key is to be attentive to client’s feedback. There are different ways to capture client feedback, some of which are client surveys like NPS, bug reports, tweets, etc. Tools that can integrate chat with the survey platform are an excellent choice. There should be an option to integrate real-time feedback that comes through social media channels like Facebook and Twitter.”
– Meenakshi Vashisht, Tips to choose the best DevOps tool for your organization, Ishir; Twitter: @ISHIR
Tips for Evaluating Free Building Tools
- Transparent coding collaboration capabilities are central to any building tool that you choose.
“Look for [building tools] that allow your teams to code in a virtual environment. This means several variations can be tested, helping you achieve better results. Develop modular software that offer easier maintenance and more reliability. Choose tools that allow your teams to collaborate on coding.
“The tools should allow Continuous Integration. This concept involves code submission in a shared system and undergoing testing. This model allows easier and reliable bug detection and fixing.”
– Dabaleena, How to Choose the Right DevOps Tools & Consulting Service?, Tech Entice; Twitter: @Tech_Entice
- Build tools should be chosen as much for their transparency as their features.
“The tool should support most or all of the tools you currently use and may use in the future.
“Let’s face it, you’re not looking for a tool that is as basic as a batch file. The build tool needs to hide the complexity of the tools which you need to automate; for example, your compilers, install builders, version control systems, etc. Do you really care what command line parameters you need to use for your compiler? Of course not, it’s much easier to fill in a field called ‘Project File’ and click a checkbox called ‘Include version information in project.’
“Also, consider what tools you’ll be using in the future. Maybe you’re thinking of moving to a .NET compiler, maybe to TeamSystem or some other Version Control System. Also, how easy is it to pass information from one step in your build process to another? Does it make it easy to store, load, manipulate and apply version information?”
– 5 Things to consider when choosing and Automated Build Tool, VSoft; Twitter: @FinalBuilder
Tips for Evaluating Free Performance Monitoring Tools
35.Teams and projects may require more than one application and server performance monitoring tool to effectively handle all automation tasks effectively.
“Application and Server Performance Monitoring: Watch for tools that will do these tasks automatically, with some being able to audit both applications and servers while others specialize in only one.”
Tips for Evaluating Free Communication Tools
- A communication tool should be evaluated on how it brings individuals across locations, the team, and those people beyond the DevOps teams together in a holistic way with machine process information.
“Modern software development needs the delivery tooling to be highly automatable. This requires a fully-featured API for each tool, preferably HTTP-based. Expect to compose capabilities by gluing together API-rich tools, enabling easy wiring for alerts and other events. Tools such as Slack provide a rich integration of human and machine activities for rapid decision-making and flow.”
– Jovile Bartkeviciute/Manuel Pais/Matthew Skelton/Rob Thatcher, How to choose tools for DevOps and Continuous Delivery, Skelton Thatcher; Twitter: @SkeltonThatcher
- Some DevOps workflows may require more than one collaboration tool, so any in consideration must be capable of seamless integration.
“DevOps and IT collaboration tools typically address very specific pain points. Creating an integrated environment of multiple, useful tools is usually a good way to ingest incident data and collaborate to resolve issues. Think about your workflow and which specific areas can cause problems for your team. Then, evaluate the tools to determine which can best address these problems.”
Tips for Evaluating Free Database Automation Tools
- Free database automation tools should be vetted to show they will actually reduce labor rather than increase it.
“Open source infrastructure [for database automation] requires implementation projects, customer time and focus, and continuous maintenance. This is not a one-time thing. It is actually an ongoing process that evolves with automation changes. The effort that your organization must invest to ensure functionality for a free database release automation tool might cost more in labor than a commercial solution.”
Tips for Evaluating Free Repository Management Tools
- Repository management tools should have a dashboard that provides a single source of truth for the software release status.
“A common dashboard for all members of Dev and Ops to see software ready for release can be a huge advantage and relieve stress. When each member of your team can see the status of a release on a single dashboard that’s integrated with your repository, there’s no need for rounds of meetings, or concern reports flying back and forth. The effort to release software is reduced when all team members have visibility into the release.”
- Every DevOps tool in consideration must be capable of integrating with the chosen code repository.
“A key feature of a repository hosting service is the integration of external tools and services. These integrations really enable the power user workflows of a repository service. Some examples of common external integrations are ticketing and task management. Customer support management tools. Automated quality assurance tools. If your team is already using a particular tool, ensure the code repository integrates with it well.”
Tips for Evaluating Free Configuration/Deployment Management Tools
- Teams must first vet their DevOps processes to ensure that any potential configuration management tool doesn’t exacerbate a problem with automation.
“Regardless of what tool you use for configuration management, the way to start your automation project is to discover what you have. Automating poor processes or poorly understood infrastructure is a fast and expensive way to multiply your problems. To truly get the most out of any automation tooling, you first need to understand where the landmines already exist.”
– 7 Configuration Management (CM) Tools You Need to Know About, UpGuard; Twitter: @UpGuard
- Deployment management tool selection requires matching each tool’s operational model with the environment, the team’s work processes, and other DevOps environment considerations to ensure they are compatible.
“There are several considerations to keep in mind when choosing a tool in this space. One is the model for the tool. Some require a master-client model, which uses a centralized control point to communicate to distributed machines, while others can or do operate on a more local level. Another consideration is the makeup of your environment. Some tools are written in different languages and support for particular OSs or setups can vary. Making sure your tool of choice will mesh well with your environment and the particular skills of your team can save you a lot of headaches here.”
- Not every DevOps tool needs to be automated to provide the greatest efficiency and transparency, as is the potential case with configuration management.
“Automation tools might make repetitive, everyday tasks a breeze, but in addition to not being idempotent, they also lack something that their bigger configuration management siblings all have. A method of keeping records of nodes and actions.
“With the added power of a database to track changes, configuration management tools have the ability to look at trends, create detailed reports, and act as an early warning against system instability. They can also use this data to further inform their automation scripts, creating powerful mechanisms for service discovery.”
– John Ray, Configuration management tools vs automation tools, Shadow Soft; Twitter: @ShadowSoftNews
- Always make development team history with configuration management tools part of the equation for evaluating new configuration tool choices.
“When selecting a configuration management tool, make sure you review your needs and the tools carefully. Investing a lot of time into one of them to learn that it’s not right for you can be costly. For example, if you’re a Ruby development team, then Chef may be a good choice for you because extending it when needed will be fairly easy since those skills already exist on the team.”
- The CM tool choice will affect current and future users, so decisions should consider possible expansion beyond the current DevOps team.
“Who will use version management, either now or in the future? Consider whether you currently experience any difficulties transitioning products among the following roles, and identify which ones will be using your SCM system:
- Software developers
- Build and release or DevOps engineers
- Quality assurance
- Designers, artists, animators, musicians, writers
- External contributors
“Each of these roles will have a preferred interface, tools and workflow for interacting with the SCM, be it via Git, a GUI or a seamless plug-in. Each role may also require different levels of training and support.”
– Seven Steps for Choosing a Software Configuration Management System, Perforce: Twitter: @perforce
- Developing a proof of concept small-scale test or other means via expert consultant input are two of the best ways to truly evaluate the compatibility of a service virtualization tool.
“Don’t simply go with the first tool promoted by a Google search or a friendly sales representative, as there’s a good chance that it might not be the most efficient choice for your specific situation. Take the time to select a tool carefully.
“Conduct a proof of concept (or more than one, ideally) that demonstrates the actual value that a tool can bring you, and that proves that a tool fits your development and testing requirements and is a good match for the skill set of your development team (or anybody that is to be made responsible for creating and maintaining the simulations). Consider hiring an independent expert that can help you make the right choice.”