DevOps Archives - Business Intelligence Info

Tag Archives: DevOps

Tasktop nabs $100M to turn DevOps metrics into visualizations at scale

April 8, 2021 Big Data

Join GamesBeat Summit 2021 this April 28-29. Register for a free or VIP pass today.

Value stream management (VSM) platform Tasktop today announced that it raised $ 100 million, bringing its total raised to over $ 129 million. The company says it plans to use the funding to accelerate growth while expanding the size of its customer base.

As traditional businesses pour billions into digital transformation initiatives, they often struggle with the complexity of the teams, tools, and metrics at the core of those investments. Technical leaders deeply understand the software development process and business leaders know the investment strategies, but the two aren’t always aligned. In a study, Geneca found that 75% of executives surveyed admitted that their projects were either “always” or “usually” doomed right from the start.

Vancouver, Canada-based Tasktop, which was founded in 2007, offers a VSM platform designed to reduce time to market and increase the velocity of software development. Sitting above the software development toolchain, Tasktop integrates with software development tools like Jira Software, ServiceNow, Azure DevOps, and more to allow organizations to see potential blockers.

VSM was born out of the frustration that most enterprises aren’t adequately adaptive. According to Forrester, only 16% say that they can release software more than once a month. For Tasktop’s part, the company asserts that VSM allows organizations to break down silos as well as identify and remove bottlenecks, eliminate waste, and accelerate delivery.

Tasktop’s platform overlays the value stream to provide abstractions, visualizations, and diagnostics that measure all types of software delivery work. Connectors let customers send work between different dev tools, eliminating duplicate data entry and automating traceability. And Tasktop’s testing regimen runs 500,000 tests daily over 300 tool versions to ensure they work properly, handling tooling and API changes to minimize outages and delays.

Coinciding with the new funding, Tasktop this morning launched a dashboard within its Tasktop Viz product — VSM Portfolio Insights — that rolls up analytics generated at the individual product value stream level to the executive plane. The dashboard presents consolidated insights into the performance, quality, value, and impact of delivery, including:

The progress of the shift from project to product-based IT
The ability to respond rapidly to the market
The business processes capable of acceleration
The value creation and value protection areas currently lacking appropriate
investment

Since the birth of VSM, the market category has grown exponentially compared with the longer-tail development of agile and DevOps. The expansion speaks for itself with players like ServiceNow, IBM, Digital.ai, and of course Tasktop joining the fray. Last December, Tasktop announced record year-over-year growth with a 30% uptick in both revenue and customers. The company now claims to serve leading brands, including over half of the Fortune 100.

Sumeru Equity Partners led Tasktop’s latest funding round, a strategic investment. Management and existing investors also participated.

VentureBeat

VentureBeat’s mission is to be a digital town square for technical decision-makers to gain knowledge about transformative technology and transact.

Our site delivers essential information on data technologies and strategies to guide you as you lead your organizations. We invite you to become a member of our community, to access:

up-to-date information on the subjects of interest to you
our newsletters
gated thought-leader content and discounted access to our prized events, such as Transform 2021: Learn More
networking features, and more

Become a member

Let’s block ads! (Why?)

Big Data – VentureBeat

How SQL Server synonyms help database DevOps

March 10, 2021 BI News and Info

Synonyms inside SQL Server are one of those useful but forgotten features. A synonym is a database level object that allows you to provide an alternative name for another database object such as a view, user defined table, scalar function, stored procedure, inline table valued function (tvf), or extended stored procedure. They can also be used for CLR Assembly related stored procedures, CLR tvf, CLR scalar functions or even CLR aggregate functions. There are many practical uses for synonyms, and I’ll explain how to create them and some use cases.

You can create a synonym using the GUI in SSMS or via a script. Here’s a sample script:

USE [AdventureWorks2014]

CREATE SYNONYM [dbo].[EmployeeDemo]

FOR [MRSurfacePro].[AdventureWorks2014].[HumanResources].[Employee]

The example creates an alternate name for the HumanResources.Employee table. Note that creating the synonym requires a four-part name, including the server. Here’s an example of how to use the new synonym:

SELECT * from dbo.[EmployeeDemo]

If you also query the original table, you’ll see that it returns the same rows. You can reference the new name in code, linked servers, applications, and more. In situations where you would need to use a three- or four-part name, you can just use the synonym without having to use the multipart naming which greatly reduces the need for code changes.

There are a few caveats to this to keep in mind. Synonyms cannot be referenced things like CHECK constraints, computed columns, default expressions, rules expressions, schema bound views or functions. They also cannot be used in DDL (Data Definition Language) statements, to make changes to the underlying schema the synonym represents, you must reference the actual object name within any DDL statement.

We all know when developing objects, the naming that was used at the beginning of a project can change and get better over time. Using synonyms can be a real project time saver. You can continue to be agile and not have a huge need to back port changes. Synonyms can also help with database migrations from one server to another. How many times have you had to migrate to a server with a new name? This simplifies the process. All you would have to do is change the synonym definition four-part name; no other changes would be required.

Imagine how easy this can make DevOps. Say you have a cross-database view and database names are different on the development server or servers in the pipeline. If you use synonyms, no additional code changes are needed when referencing the view, and a post-deployment script could just change the synonym definition depending on the environment.

Synonyms simplify and remove the need for code changes. It’s definitely something to consider. I am always cautious as a DBA to recommend things like this as it tends to make it more difficult to track down issues and troubleshoot back to the original table or source, so be sure to document them. There are times, however, in which we need to accomplish things as I explained above, and synonyms are a great avenue to do so.

Commentary Competition

Enjoyed the topic? Have a relevant anecdote? Disagree with the author? Leave your two cents on this post in the comments below, and our favourite response will win a $ 50 Amazon gift card. The competition closes two weeks from the date of publication, and the winner will be announced in the next Simple Talk newsletter.

Let’s block ads! (Why?)

SQL – Simple Talk

How Microsoft Azure DevOps and Dynamics 365 CRM Work Together to Improve Service Responsiveness

February 24, 2021 Microsoft Dynamics CRM

An upset customer calls. My system is down! This feature doesn’t work! While many issues are open and closed cases (or are the result of user error), there may be bugs that need to be addressed by the development team. Having a centralized place for your customer information is just one CRM function. Your CRM can also reduce inefficiencies in application support and management, especially when effectively connected to other systems. Integrating applications such as Microsoft Dynamics 365 CRM with Azure DevOps services amplifies case management capabilities for your development and support teams to escalate support cases and create work items to get problems resolved faster.

Outside of tech support’s ability to keep their cool when faced with high-stress situations, they must also act quickly. The more complicated the process and more systems involved, the longer it takes to get the ticket assigned to the right person or team. To help meet troubleshooting service goals, you need an open flow of communication right back to the source — the software development team.

Azure DevOps covers every step in the application lifecycle from planning, collaborating and testing, deployment, and beyond. If your business develops and/or hosts web or mobile apps, Azure DevOps services, integrated with Dynamics 365 CRM, can provide the full visibility across projects that your software development and tech support teams need.

Azure DevOps Services

Azure is a flexible public cloud computing platform that provides Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). Continuous delivery (CD) and continuous integration (CI) pipelines enable your software development teams to get a constant flow of updates — new features, configurations, bug fixes — into production and delivered to your customers quickly and safely.

Microsoft Azure DevOps services allow you to build, test, deploy and manage applications and services. Your software development teams can use all these DevOps services together, or mix and match to use only what you need as part of your existing workflows.

Depositphotos 120503924 xl 2015 625x417 How Microsoft Azure DevOps and Dynamics 365 CRM Work Together to Improve Service Responsiveness — Business meeting between four upper management board members in the new modern office conference room with technology integrated in the form of an electronic tablet.

Azure Boards: Agile tools, Kanban boards, team dashboards, built-in scrum boards and more — Azure Boards is where your team will plan, track and discuss projects at every stage in the lifecycle. Backlog tracking and powerful analytics give insight into project status. With visualizations and tracking tools, your team can easily track any code changes that are linked directly to work items.

Azure Pipelines: Azure Pipelines comprise the whole end-to-end story of how you write code and get it into production. An integrated set of features allow you to automatically build and test your web, desktop and mobile applications and deploy to any cloud or on-premises. It works with just about any language or project type including Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android and iOS apps, as well as support for YAML so you can have pipelines versioned with your code.

Azure Test Plans: A browser-based test management solution, Azure Test Plans provides all the capabilities to test with confidence before deployment. This includes planned manual testing, user acceptance testing, exploratory testing, and gathering feedback from stakeholders. You can test across desktop and web apps, as well as capture data as tests are executed.

Azure Artifacts: Package management with Azure Artifacts simplifies complex build jobs and allows your teams to create and share Maven, npm, NuGet, and Python package feeds. Artifacts provide a place to push your packages so that they can be consumed by the rest of the team or partners. Sources can be public and private.

Azure Repos: This is where your source control is stored that gets published to the artifacts. Unlimited, cloud-hosted Git repos allow developers to collaborate on code.

Depositphotos 218890680 xl 2015 625x417 How Microsoft Azure DevOps and Dynamics 365 CRM Work Together to Improve Service Responsiveness — Working together in office. Business concept with double exposure effects

Before deploying Azure DevOps tools for your software development teams, it is wise to pre-plan how you will support and operate services in the cloud. To learn more about some of the key questions to ask before moving forward, read the full blog.

Get Started with JourneyTEAM

JourneyTEAM was recently awarded Microsoft US Partner of the Year for Dynamics 365 Customer Engagement (Media & Communications) and the Microsoft Eagle Crystal trophy as a top 5 partner for Dynamics 365 Business Central software implementations. Let JourneyTEAM show you the benefits of integrating Dynamics 365 and Azure DevOps Services. We can provide demos and full custom introductions. Contact JourneyTEAM today!

Article by: Dave Bollard – Chief Marketing Officer

801-436-6636

JourneyTEAM is an award-winning consulting firm with proven technology and measurable results. They take Microsoft products; Dynamics 365, SharePoint intranet, Office 365, Azure, CRM, GP, NAV, SL, AX, and modify them to work for you. The team has expert level, Microsoft Gold certified consultants that dive deep into the dynamics of your organization and solve complex issues. They have solutions for sales, marketing, productivity, collaboration, analytics, accounting, security and more. www.journeyteam.com

Let’s block ads! (Why?)

CRM Software Blog | Dynamics 365

Recruiting DBAs for DevOps

February 13, 2021 BI News and Info

Experienced DevOps professionals have the responsibility to assimilate new people into the movement. DBAs coming on board need to understand (and possibly be convinced) that DevOps is about improving and quickening a continuous flow of software or web service improvements designed to provide a richer customer experience, abounding with excellent performance and extreme availability. DBAs need to change many habits to blend traditional work into the DevOps model. This article examines recruiting DBAs for DevOps.

DBA “Undersight”

DBA work has been a “black box” for too long that can seem like “magic” to everyone else. Reality shows that DBA scripts, database performance configuration changes, login triggers, and other DBA outputs are not scrutinized enough nor managed properly. The change advisory board (CAB) team may ask a question or two about why the change is needed, but many CAB members probably do not have the required knowledge to question the change enough to understand the potential harm. I hear what you are thinking, “The CAB does not have the technical experience to interrogate most changes.” I agree, but I also maintain the position that the CAB members see fewer database changes (compared with application changes) and fail to realize that database change mistakes tend to lean toward catastrophic. I believe it’s because the CAB should not be evaluating changes. The product owner and DevOps team members should know when to deploy because they intimately know the readiness of the code, understand the consequences of failure, and are working the backlog based on value. DevOps protects the teams from consequences if the teams abide by the mandates to excessively test to code and never allow a defect to be deployed into production. DBAs and DevOps team members surely agree to this value proposition, not needing oversight for releases. You’ll have to persistently engage the DBAs to shift expectations in order to incorporate their work into the release cycle.

“Bridg-ers”

Although DBAs fortunately have the rare ability to bridge the gap between development and operations, they have been detrimentally overlooked in many companies that deploy DevOps practices. A DBA’s ability to interrogate code and construct a resilient, well–performing database environment uniquely defines the capabilities needed for DevOps. DevOps requires transformation from organizational silos defined by a technology skill set to process-driven, continuous flowing work streams that are empowered by collaboration and automation. DevOps is about speed, delivery time, continuous integration and deployment, release cadence, and superior customer experience. Although metrics are critical for measuring customer experiences such as application responsiveness, they are also needed to measure release success rate, software defects, test data problems, work, and more. DBAs tend to be strong technical leaders who provide insight into coding best practices, host platform configurations, database performance improvements, data security and protection. To be successful, DBAs have to communicate, collaborate, teach, and learn while continuously improving database performance and availability. The job often includes having to meet with development to discuss poor performing code, index requirements, or execution plans to recommend code remediation. These “normal” interactions are imperative to the success of DevOps, leaving me perplexed about why DBAs were not one of the first operations team members asked to join the DevOps movement.

Transition

Understanding that DBAs are “built” in significantly different ways should help with the approach. Many DBAs were once developers, others came from various infrastructure roles, and still others have always been DBAs. Determining which DBA type is easier to bring into the fold is a fool’s game. DBAs are people, and people are surprisingly unpredictable. One ex-developer DBA may be excited to finally be able to use both skillsets to help advance DevOps, whereas another may be perturbed by having to dig up old skills she had hoped were long dead and buried. Individually interviewing and evaluating each DBA may be necessary. Much like interviewing potential employees, discernment is needed to assess fit, training needs, and potential disruptive factors that may impact the existing DevOps team members. The right leaders and SMEs need to be involved and dedicated to the time and effort needed to integrate DBAs. Rest easy; the good news is that even if some DBAs may resist, they all want to provide value by improving the environment. Besides, as you start to expand participation in DevOps, you already have a handful of people in mind to make the voyage smoother. You know who I’m talking about. Yes, the ones you see talking to the development teams on a regular basis, checking in to see how things are going, seeing what changes are coming down the pipe, asking what the application users are saying about performance, and even offering to assist as needed. These people should be your initial picks to join the DevOps team. Specifically, you should find DBAs who are already engaged, bring them on board, and then let them help you select and onboard other DBAs when needed. Having a trusted and respected DBA doing the team’s bidding for additional DBA talent is likely to result in volunteers. People want to work with people with whom they have an established relationship. Leverage previous successful working relationships to resourcefully construct the DevOps team.

Reciprocal Teaching

Whether through formal methods such as classroom or virtual training, job shadowing, and mentoring; or through informal methods such as team discussions or presentations, teaching needs to be a frequent element of team integration. It is a given that IT and business teams have difficulty understanding each other without a common taxonomy. Even teams within IT often fail to understand each other. A developer discussing encapsulation or inheritance may totally perplex a DBA unfamiliar with object-oriented programming terminology. Never mind if you start talking about Agile, which is very new to many IT professionals. Likewise, a DBA ranting about developers “thrashing” the buffer cache is likely to see the “deer in the headlights” stare. While investigating a performance issue specific to a screen, a developer shared with a DBA that the drop-down window would display ten data elements from which the application user could select. As they looked at the code and then tested the code in a non-prod environment, they learned that the result set was millions of records. The million records would move from the database to the middle tier, and then the needed to rows would be pushed to the client application screen. When asking why millions of rows were being returned, the developer said that was a standard practice. After looking into other queries, the DBA soon found herself ranting to several development managers about the developers thrashing the buffer cache and the performance impact. After realizing that these managers did not understand DBA “technical” jargon, she determined that there was a better way to communicate the message. She scheduled a meeting a few days later, in which she put together a presentation deck outlining basic buffer cache concepts with visuals (see Figure 1) that demonstrated how large result sets can negatively impact not only the query requesting the data but also every aspect of the database performance. After the DBA spent an hour walking the developers through the presentation and answering questions, these developers understood the impact of less-selective queries. As days and weeks passed, and often when the DBA was visiting the developer realm, developers would jokingly remind each other to not thrash that buffer cache unless they wanted the DBA to get after them. Although the training was succinct and simplified, it closed the language gap, resulting in improved query selection criteria, smaller result sets, and less buffer cache “thrashing.” The point is that even people in the same industry do not necessarily speak the same language. DevOps introduces another language gap that requires purposeful definition to keep all members of the team aligned. This book presumes that readers are technically savvy and already familiar with DevOps and the core terminology, but it may not be true as they begin working with DBAs. Accelerating DBA engagement requires DBAs to understand the DevOps principles and foundational constructs. Experienced DevOps team members need to educate DBAs on processes, continuous integration and delivery, and the implemented toolset. Demonstrating how code is built, tested, integrated, and released helps DBAs determine where best to interject changes supporting the code cycle. DBAs also need early notification when system changes are necessary, allowing time for the reconfiguration to be completed, tested, security approved, and automated for pipeline consumption.

word image 77 Recruiting DBAs for DevOps

Figure 1. Buffer cache thrashing

Molding DBAs

Adding DBAs to Dev Ops teams gives the DevOps team members the opportunity to “mold” the DBAs. Previous challenges of getting a DBA to even consider a nonrelational database solution becomes an opportunity for the DBA to learn new database technologies. Just climbing over the fence gives new perspective. Once DBAs buy into DevOps, learn the processes, and fully understand how database work can benefit the business, instead of the development team (the previous customer), the pipeline expands from database change introduction, growing the code base as DBAs check in database changes and infrastructure as code templates and scripts. Cycle time shrinks from database changes no longer being an outlier to the process. Deployments smooth out and complete faster as DBA work is automated.

DBA Value Proposition

DBA participation in DevOps draws in a critical application availability and performance contributor: the database. Involving DBAs means that application code is evaluated from a different perspective, especially calls to the database. Database changes become integrated code for continuous integration and exhaustive testing. DBAs can identify poorly executing queries and transactions and baseline production performance. They can get ahead of forthcoming code changes or new functionality by understanding the impact on the preprod environments, which gives DBAs time to analyze and implement performance-tuning enhancements before the additional load is present. Problems become challenges for a larger team, compiling more experiences and skills into the pool of contributors to determine root cause and deploy mitigation. DBAs’ experiences in other infrastructure areas add another layer of value by being able to assess the application and database by looking under the covers at the operating systems, storage, and network. Further discussion is ahead. Closer and constant DBA and DevOps team collaboration improves product outcomes, stability, security, and performance, which lead to happier customers and improved business results. As DBAs better understand the business team’s use of the product, building a disaster recovery solution or recovery from backup strategy can be customized Giving developers the freedom to fire up virtual hosts with different database options enables consideration of risk early in the process. A developer wanting to test a new data access service can test, retry, and destroy the virtual host to start over with a fresh host if necessary. DBAs scripting different template options applicable to different data platforms shifts experimentation from production too early in the pipeline.

DBAs are a good match for DevOps. Driven to improve performance, reliability, and system stability; and matched with the skills to adapt, analyze, and execute process improvements, DBAs can expand the DevOps team’s capabilities; reduce cycle time by pulling database changes into the continuous integration process; contribute new test cases for improved bug detection; and get ahead of performance, load, and other operational challenges before production impact. By investing in DBAs joining DevOps teams, DevOps leaders and engineers increase influence and impact on the business. Applying proven DevOps processes to database changes, build templates, database selections, and broader platform considerations presents new opportunities that may have been previously resisted by the same DBAs. DBAs get excited when their contribution can grow, they can grow, and the business can grow.

If you liked this article, you might also like Ten tips for building a collaborative DevOps culture.

Let’s block ads! (Why?)

SQL – Simple Talk

Tagging In Azure DevOps

November 8, 2020 Microsoft Dynamics CRM

What is Tagging? Tagging has long been a term used to describe a kind of graffiti to mark public spaces. In Azure DevOps (or ADO), tagging is similar because it can serve as a colorful label for work items to visually distinguish one epic from another, isolate a critical user story from hundreds of others, and so on. The big difference here is that tags in ADO should be encouraged (though…

Source

Let’s block ads! (Why?)

PowerObjects- Bringing Focus to Dynamics CRM

10 DevOps strategies for working with legacy databases

November 1, 2020 BI News and Info

Database teams often maintain large and complex legacy databases that they must keep operational to support existing applications. The teams might have maintained the databases for years, or they might have inherited them through acquisitions or other circumstances. Whatever the reasons, they likely manage and update the databases in much the same way they always have, performing their tasks mostly segregated from other efforts. But this approach makes it difficult for organizations to fully embrace modern application methodologies such as DevOps, which rely on more agile and aggressive application delivery processes.

The traditional methods for maintaining legacy databases can slow application delivery, impact productivity, and increase overall costs. Some organizations are starting to incorporate databases into their DevOps processes, but it’s not always an easy goal to achieve. Application and database development have historically been much different, and synchronizing changes can be a significant challenge. Another serious consideration is data persistence, which plays a major role in database updates, but is of little importance to the applications themselves.

Despite these issues, many organizations have come to recognize the importance of incorporating databases into the DevOps model. By applying the same principles to databases as those used for delivering applications, they can better control the entire application development and deployment process, including the databases that go with them. For organizations ready to make the transition, this article offers 10 strategies for incorporating legacy databases into their DevOps pipelines.

1. Choose your database strategy wisely.

Before embarking on your database DevOps journey, give careful consideration to how you should proceed. Start by identifying your business objectives and long-term strategies. In some cases, it might not be worth investing the time and resources necessary to apply DevOps to a legacy database. For example, the database might support applications that will soon be phased out, in which case, you might need to focus on how to migrate the data, rather than continuing to support the legacy database.

For those databases that you’ll continue to support, keep the overall scope in mind. It’s better to take one small step at a time than try to bring every database into the DevOps fold all at once. You should be planning for the long-term and not trying to do everything overnight. You might start with a small database to see how the process goes and then move on from there, or you might deploy a new database so your database team can become familiar with DevOps principles before tackling the legacy databases.

2. Create a DevOps culture that includes the database team.

Discussions around DevOps inevitably point to the importance of creating a culture of collaboration and transparency, one that fosters open communications for all individuals involved in application delivery. DevOps team members should be encouraged to work together and share in the responsibility for application delivery, adopting a mindset in which everyone has a stake in the outcome.

Not that long ago, DevOps teams rarely included database team members, leaving them out of the discussion altogether. For the most part, databases were seen as completely separate entities from the applications they served. However, the only way to successfully incorporate legacy databases into the DevOps process is to ensure that the database team is as much a part of the DevOps effort as the development and operations teams. The better the communications between the database team and everyone else, the smoother the transition to database DevOps.

3. Get the right tools in place.

DevOps teams need the right tools to support the continuous integration/continuous delivery (CI/CD) pipeline common to DevOps deployments. For example, a team might use Chef for configuration management, Jenkins for build automation, Kubernetes for deploying containers, or NUnit for unit testing. The exact tools depend on an organization’s specific requirements and the type of applications they’re deploying. DevOps teams should select their tools carefully, taking into account the growing need to support database deployments.

Initially, DevOps solutions tended to leave databases out of the equation, but that’s been steadily changing. Many DevOps tools now accommodate databases, and many database tools now accommodate DevOps. For example, Redgate Deploy can help incorporate a database into the CI/CD pipeline and can integrate with any CI server that supports PowerShell. Redgate Deploy can also integrate with common CI and release tools, including Jenkins, GitHub, TeamCity, or Azure DevOps.

4. Prepare the database team for DevOps.

DevOps methodologies require special skills to ensure that applications are properly built, tested, and deployed to their various environments. If developers also implement infrastructure as code (IaC), DevOps teams require skills in this area as well. In some cases, an organization might need to bring on additional personnel or outside consultants. For many DevOps teams, however, all they need is enough training and education to get them up and running. This is just as true for the database team as anyone else.

For example, individuals on the database team might focus on specific areas, such as Oracle database development or SQL Server administration. To prepare them for a transition to database DevOps, they should be trained in DevOps methodologies, particularly as they apply to database deployments. In this way, they’ll be much better prepared for the transition and able to understand why specific steps need to be taken. They’ll also be able to more effectively communicate with other DevOps team members about CI/CD operations.

5. Document your databases and data.

When preparing your databases for the transition to DevOps, you should ensure that they’re fully documented so that everyone on the DevOps team can quickly understand how a database’s objects are used and how they impact the application as a whole. Anyone looking at the documentation should be able to understand the types of data being stored, how the data is related, and any special considerations that might apply to the data.

One approach to documentation is to use the features built into the database platform. For example, SQL Server supports extended properties, which can be leveraged to document individual objects. In this way, the data definitions are stored alongside the schema definitions, providing immediate access to the information when needed. Better still, the extended properties also get checked into source control when the schema files are checked in (assuming that source control is being used, as it certainly should be).

6. Get databases into version control.

Many database teams are already putting their database script files into source control for maintaining file versions, often along with lookup or seed data. The databases might not participate in DevOps processes, but the source files are still protected. If a database team is not using source control, they’ll need to start. Version control is an essential part of DevOps methodologies. It offers one source of truth for all code files, resulting in fewer errors or code conflicts. It also provides a record of all changes, and it makes it possible to roll back changes to a previous version.

Database teams should store all their database code in source control in a product like SQL Source Control, without exception. This includes the scripts used to build the database as well as change scripts for modifying the schema. It also includes scripts used for creating stored procedures and user-defined functions, as well as any data modification scripts. In addition, it’s a good idea to store static data into source control, such as that used for lookup data, as well as configuration files when applicable. Source control check-ins should also incorporate code reviews to reduce the possibility of errors.

7. Prepare for data migration.

When you update an application, you don’t have to worry about persisting data from one version to the next. It’s not so easy with databases. You can’t simply update or replace schema without considering the impact on data. Even a minor update can result in lost or truncated data. With any database update, you must take into account how your changes will impact the existing data, what steps you must take to preserve that data, and how to apply any new or modified data to the updated database.

When preparing to incorporate your databases into DevOps, you need to have in place a system for ensuring that any new database versions get the data they need. If you’re doing an in-place schema update, you might also need scripts for modifying and preserving data. If you’re re-creating the database from scratch, you need the scripts necessary to populate the tables. In either case, those scripts should be checked into source control along with the schema changes, so they’re included in the CI/CD build process.

8. Shift left in your thinking.

DevOps methodologies include the concept of shifting left, which refers to the idea of performing certain tasks earlier in the application lifecycle. For example, instead of waiting to build the application and test its code until late in the development cycle, building and testing become an ongoing process that takes place as soon as updated script files are checked into source control. Also important to this process is that code check-ins occur frequently and in smaller chunks. The shift-left approach makes it easier to address issues sooner in the development process when they’re far more manageable.

The shift-left strategy should also be employed when incorporating databases into the DevOps pipeline, with developers checking in their script files on a frequent and ongoing basis. In addition, they should create database-specific tests, such as ones that verify object structure or query results. That way, when a developer checks in code changes, the CI server builds the database and runs the tests so that each change checked into source control is immediately verified. This doesn’t preclude other types of testing later in the cycle, but it helps catch certain issues earlier in the process when they’re much easier to resolve

9. Automate database operations.

Automation is a key component of a successful DevOps operation. This applies to the core application as well as the database. Automation helps avoid repetitive tasks, reduces the potential for errors, and ensures consistent results with each deployment. To this end, DevOps teams must ensure that the build, test, and deployment operations incorporate the database script files along with the application files. This might mean acquiring new CI/CD tools that can better accommodate databases or reconfiguring existing one to handle the additional requirements.

The key, of course, is to ensure that the database developers are checking their files into source control and following a consistent, agreed-upon process for managing script files. For example, they should decide whether to take a state-based approach or migration-based approach to deploying database updates. Although it’s possible to employ both strategies, choosing one over the other makes it easier to collaborate on a single code base while avoiding the complexities of balancing both at the same time.

10. Perform ongoing monitoring.

Like automation, continuous monitoring is an essential component of a successful DevOps operation. This includes monitoring the systems themselves, as well as providing continual feedback at every stage of the DevOps process. Comprehensive monitoring ensures that everything is functioning properly, while helping to identify issues early in the development cycle. Not only does this make for better applications, but it also helps to improve the CI/CD process itself.

Most DBAs are already familiar with the importance of monitoring their production database systems for performance, security, and compliance issues. In all likelihood, they already have the tools in place for identifying issues and determining which ones need immediate attention. The continuous feedback loop represents a different type of monitoring. It provides database developers with visibility across the entire pipeline and alerts them to any problems with their script files during the integration, testing, and deployment phases. For this reason, you must ensure that your pipeline’s feedback loop takes into account the database script files at every phase of the operation.

Looking to the future

All databases have a limited lifespan, and it’s just a matter of time before your legacy databases must be overhauled or replaced with another system. For example, you might find that a document database such as MongoDB will better serve an application than a relational database. Many organizations are also looking for ways to better accommodate the persistent data requirements that go with containers, microservices, and cloud-based applications.

No matter what direction your organization is heading, chances are it’s moving toward a goal of faster release cycles and greater agility. Database teams are under increasing pressure to adopt this strategy and take a more flexible approach to database maintenance. Instead of thinking of databases as unmovable monolithic structures, they must learn to treat them as manageable code that can be tested, automated, and deployed just like application code. DevOps can make this transition a lot easier, while also preparing database teams for what might be coming in the future.

Let’s block ads! (Why?)

SQL – Simple Talk

Monitoring the Power Platform: Azure DevOps – Orchestrating Deployments and Automating Release Notes

August 31, 2020 Microsoft Dynamics CRM

Summary

DevOps has become more and more ingrained into our Power Platform project lifecycle. Work item tracking and feedback tools for teamwork. Continuous integration and delivery for code changes and solution deployments. Automated testing for assurance, compliance and governance considerations. Microsoft’s tool, Azure DevOps provides native capabilities to plan, work, collaborate and deliver. Each step along the way in our Power Platform DevOps journey can be tracked and monitored which will be the primary objective of this article.

In this article, we will focus on integrating Azure DevOps with Microsoft Teams to help coordinate and collaborate during a deployment. We will explore the various bots and how to set them up. From there we will walk through a sample scenario involving multiple teams working together. Finally, we will look to automate release notes using web hooks and Azure Function.

Sources

Sources of Azure DevOps events that impact our delivery can come from virtually any area of the platform including work items, pipelines, source control, testing and artifact delivery. For each one of these events, such as completed work items, we can setup visualizations such as charts based on defined queries. Service hooks and notification subscriptions can be configured to allow real time reporting of events to external parties and systems allowing for us to stay in a state of continuous communication and collaboration.

AUTHOR NOTE: Click on each image to enlarge for detail.

3288.pastedimage1598622673004v1 Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Microsoft Teams, Continuous Collaboration and Integration

Azure DevOps bots with Microsoft Teams has quickly grown into one of my favorite features. For instance, Azure DevOps dashboards and kanban boards can be added to channels for visualizations of progress as shown below.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Multiple Azure DevOps bots can be configured to deliver messages to and from Microsoft Teams to allow for continuous collaboration across multiple teams and channels. These bots can work with Azure Pipelines, work items and code pull requests.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

For monitoring and orchestrating deployments across our various teams, the Azure Pipelines bot is essential. Let’s begin by setting up subscriptions to monitor a release pipeline.

NOTE: The rest of this document will be using a release pipeline as an example, but this will also work with multi-stage build pipelines that utilize environments.

Configuring the Azure Pipelines Bot in Microsoft Teams

Use the “subscriptions” keyword with the Azure Pipelines bot to review and modify existing subscriptions and add new ones.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

In the above example, we are subscribing to any changes in stages or approvals for a specific release pipeline. Its recommend to filter to a specific pipeline to reduce clutter in our Teams messaging. The Azure Pipeline bot, using actions described in the article “Azure DevOps – Notifications and Service Hooks“, can be further filtered by build statuses. This is helpful to isolate the messages delivered to a specific Teams channel.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Once configured, as soon as our pipeline begins to run, Microsoft Teams will begin to receive messages. Below is an example showing the deployment of a specific release including stages and approval requests. What I find nice about this is that Microsoft Teams works on both my mobile devices and even Linux based operating systems, allowing any team on any workload to utilize this approach.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

I also want to point out that Azure DevOps also has the ability to natively integrate with other 3rd party tools such as Slack (Similar to the Teams bots), ServiceNow and Jenkins.

Release Pipelines

Quality Deployments

Deployments within a release pipeline allow for numerous ways to integrate monitoring into Azure DevOps processes. Each deployment include pre and post conditions which can be leveraged to send events and metrics. For instance, the Azure Function gate can be used to invoke a micro service that writes to Azure Application Insights, creates ServiceNow tickets or even Kafka events. The possibilities are endless, imagine sending messages back to the Power Platform for each stage of a deployment!

Approvals

Pre and Post approvals can be added to each job in the release pipeline. Adding these can assist during a complex deployment requiring coordination between multiple teams dispersed geographically. Shown below is a hypothetical setup of multiple teams each with specific deliverables as part of a release.

7002.pastedimage1598622673008v10 Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

In this scenario, a core solution needs to be deployed and installed before relying features can begin. When any of the steps in the delivery process begins, the originating team needs to be notified in case of any issues that come up.

Using approvals allows the lead of the specific feature team to align the resources and communicate to the broader team that the process can move forward. The full example can be found below.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Here is an example of an approval within Microsoft Teams, notifying the lead of the core solution team that the import process is ready. The approval request shows the build artifacts (e.g. solutions, code files, etc), the branch and pipeline information.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Deployment Gates

At the heart of a gated deployment approach is the ability to search for inconsistencies or negative signals to minimize unwanted impact further in the process. These gates, which can be set to run before or after a deployment job, allow us to query for potential issues and alerts. They also could be used to notify or perform an operation on an external system.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Queries and Alerts

Deployment gates provide the ability to run queries on work items within your Azure DevOps project. For instance this allows release coordinators and deployment managers to check for bugs reported from automated testing using RSAT for Dynamics 365 F&O or EasyRepro for Dynamics 365 CE. These queries are created within the Work Items area of Azure DevOps. From there they are referenced within the pipeline and based on the data returned, upper and lower thresholds can be set. If these thresholds are crossed, the gate condition is not successful and the process will halt until corrections are made.

External Integrations

As mentioned above Azure Function is natively integrated within deployment gates for Release Pipelines. These can be used for both a pre condition and post condition to report or integrate with external systems.

Deployment gates can also invoke REST API endpoints. This could be used within the Power Platform to query the CDS API or run Power Automate flows. An example could be to query the Common Data Service for running asynchronous jobs, creating activities within a Dynamics 365 environment or admin actions such as enabling Admin mode. Another could be to use the robust approval process built in Power Automate for pre and post approvals outside of the Azure DevOps licensed user base.

Using Build Pipelines or Release Pipelines

In the previous section I described how to introduce quality gates to a release securing each stage of the pipeline. Release pipelines are useful to help control and coordinate deployments. That said, environments and build pipelines allow for use of YAML templates which are flexible across both Azure DevOps and GitHub and allow for teams to treat pipelines like other source code.

Environments

Environments in Azure DevOps allow for targeted deployment of artifacts to a collection of resources. In the case of the Power Platform, this can be thought of a release to an Power Platform environment. The use of pipeline environments is optional, that is unless you begin work using Release pipelines which do require environments. Two of the main advantages of environments are deployment history and security and permissions.

Environment Security Checks

Environment security checks, as mentioned above, can provide quality gates similar to the current capabilities of Release Pipelines. Below is an example of the current options compared to Release Pre and Post Deployment Quality Gates.

3603.pastedimage1598622673009v14 Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Here is an example of linking to a template in GitHub.

0876.pastedimage1598622673009v15 Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Compare this to the Release Pipeline Pre or Post Deployment Quality Gates.

Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Scenario: Orchestrating a Release

Ochestrate%20Release%20with%20Teams%20 %20Full Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

In the above example, we have a multi-stage release pipeline that encompasses multiple teams from development to support to testing. The pipeline relies on multiple artifacts and code branches for importing and testing.

In this example, we have a core solution containing Dynamics 365 entity changes that are needed by integrations. They will need to lead the deployment and test and notify the subsequent teams that everything has passed and can move on.

Below is an example of coordination between the deployment team and the Core team lead.

Ochestrate%20Release%20with%20Teams Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Below is an image showing the entire release deployment with stages completed.

4760.pastedimage1598622673010v19 Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

Automating Release Notes

Azure Application Insights Release Annotations

The Azure Application Insights Release Annotations task is a marketplace extension from Microsoft allowing a release pipeline to signal an event in a release pipeline. An event could be the start of the pipeline, the end, or any event we are interested in. From here we can use native functionality of Azure Application Insights to stream metrics and logs.

Using an Azure Function with Web Hooks

Service Hooks are a great way of staying informed of events happening within Azure DevOps allowing you to be freed up to focus on other things. Examples include pushing notifications to your teams’ mobile devices, notifying team members on Microsoft Teams or even invoking Microsoft Power Automate flows.

2043.pastedimage1598622673010v20 Monitoring the Power Platform: Azure DevOps Orchestrating Deployments and Automating Release Notes

The sample code for generating Azure DevOps release notes using an Azure Function can be found here.

Next Steps

In this article we have worked with Azure DevOps and Microsoft Teams to show an scenario to collaborate on a deployment. Using the SDK or REST API, Azure DevOps can be explored in detail, allowing us to reimagine how we consume and work with the service. This will help with automating release notes and inviting feedback from stakeholders.

Previously we looked at setting up notifications and web hooks to popular services. We then reviewed the Azure DevOps REST API to better understand build pipelines and environments.

If you are interested in learning more about specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, please contact your Technical Account Manager or Microsoft representative for further details.

Your feedback is extremely valuable so please leave a comment below and I’ll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.

Index

Monitoring the Power Platform: Introduction and Index

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

A Practical Guide To DevOps For ERP

June 7, 2020 BI News and Info

Part of the “DevOps for ERP” series

Whether or not you believe in the value that DevOps can offer to a business – and there’s already plenty of evidence to show that it can deliver major benefits – there’s no doubt that more and more companies are starting to wonder why they haven’t extended this approach to their ERP systems.

Not so long ago, I regularly had to explain what agile and DevOps meant, but nowadays, people come to us asking how we can help them adopt these approaches.

So why the change? Transformation is the key. It’s a word that’s a bit overused by my colleagues in the marketing world, in my opinion. But with the move to cloud, the constant emergence of new technologies, and growing pressure on businesses to innovate and increase competitiveness, real changes are happening that IT teams simply have to respond to.

Perhaps unlike in years gone by, ERP teams are not immune to this trend. As “systems of engagement” like websites and mobile apps change faster than ever, the “systems of record” that often power them need to keep pace. Otherwise the whole business slows down.

Unfortunately, the ERP development processes most people have been familiar with throughout their careers – the “waterfall” method most often still in use today – tend to suffer from a slow pace of change. This can be explained by the concern that changing things in ERP systems has traditionally come with a high chance of failure (an unacceptable outcome for business-critical systems).

DevOps, on the other hand, supports application delivery in shorter, more frequent cycles where quality is embedded from the start of the process, and risk is substantially reduced.

Great, I hear you say; let’s do it! However, even the most enthusiastic organizations cannot implement DevOps in ERP systems in exactly the same way as they’ve done for other applications. The fundamental requirements for DevOps are the same – I covered some of them here – but the practicalities are different, not least because standard DevOps tools aren’t capable of doing the job. What’s more, the DevOps experts don’t necessarily understand what’s needed in ERP, while the ERP experts may never have heard of DevOps!

What is the practical reality if companies do adopt DevOps for ERP?

Higher-quality development

Delivering software at high speed requires a robust development process that combines clear business requirements and constant feedback. DevOps mandates that ownership of quality “shifts left” and is embedded from the very start of the process. This way, most (and ideally all) problems can be identified long before they get to live production systems (where the disruption caused and associated cost to fix are much greater).

In practice, this means we need to ensure that nothing leaves development without being fully quality-checked. Working practices like daily stand-up sessions, mandatory peer reviews of code, and a set of universal coding standards might not seem revolutionary for some IT teams, but they are new ideas for many ERP professionals. They’re only part of the solution, though, going along with technical elements like automated unit testing and templated lock-down of high-risk objects.

One other practical outcome of DevOps from the very first stage of development is that ERP and business teams must be more closely aligned to ensure that customer requirements are clearly understood. Integration between the development team and other IT functions like QA and operations also establishes an early validation step.

Low-risk, high cadence delivery

Continuous integration is an aspect of DevOps that means that – unlike in many ERP landscapes – changes can be successfully deployed to QA or any other downstream system at any time without risk. The big change here is the ability to deploy based on business priorities, rather than just having to wait for the next release window.

Automation gives you the means to achieve this new high-frequency delivery cadence in ERP systems by providing a way to better manage risk (spreadsheets definitely do not form a core part of a DevOps-based software delivery process!). It enables you to check every change for technical issues like completeness, sequencing, dependencies, risk, and impact and more, ensuring that nothing is promoted prematurely.

This more rigorous, agile approach means QA teams, in particular, can focus their attention on real issues rather than technical “noise,” which accelerates the delivery of functionality that business users or customers are waiting for. Changes can be selectively and automatically deployed with confidence, rather than waiting for the next full release.

Minimal production impact

“Stability is king” has long been an unofficial mantra in ERP environments, given their importance to day-to-day business operations. With DevOps, the required system stability is maintained even though live production systems can be updated far more often. Rigorous controls – built on both technical solutions and new collaborative workflows – ensure that deployments are safely delivered to end users as soon as possible.

But there is always a risk, however small, that a change to live ERP systems can cause problems that stop the business. That’s why Mean Time To Recover (as opposed to the more traditional Mean Time To Failure) is a key DevOps metric. The most effective ERP DevOps processes feature a back-out plan that allows changes to be reversed as quickly as possible so, even if disaster strikes, the impact of change-related downtime is minimal, and business continuity can be maintained.

The culture question

As I’ve explained, when implemented correctly, DevOps fundamentally changes traditional ERP development processes. However, the manner in which DevOps impacts the roles and approach of staff can be just as important. In DevOps, effective collaboration is key. Traditional silos based on job function are replaced by multi-skilled, cross-functional teams that work together to deliver agreed-upon business outcomes. This may require a significant shift in how teams are organized.

It’s normal for some people to find this new way of working challenging, but creating a successful DevOps culture empowers team members to take responsibility at every stage of the development lifecycle. It enables them to collaborate with their colleagues and focus on a common goal of rapidly delivering the high-quality features and functionality the business needs to remain competitive.

DevOps benefits and outcomes

Change happens fast, and companies need to respond quickly. IT systems must, therefore, have the flexibility to rapidly change, expand, extend, and adapt.

But accelerating delivery cannot be done at the expense of business continuity. Successfully adopting DevOps for ERP combines speed, quality improvements, and risk reduction. That provides the flexibility to change ERP environments at the speed the business needs with confidence that it can be achieved without compromising stability.

For more on this topic, please read “How to Build a Business Case for DevOps” and “Self-Assessment: Are You Already Doing ERP DevOps?”

For a practical guide on how to introduce DevOps to your ERP software development and delivery processes, download our e-book.

A version of this article originally appeared on the Basis Technologies blog. This adapted version is republished by permission. Basis Technologies is an SAP silver partner.

Let’s block ads! (Why?)

Digitalist Magazine

CRM Software Revolution with DevOps

June 2, 2020 Microsoft Dynamics CRM

In today’s uncertain market, businesses focus on the agility to become more proactive and reactive towards market changes, new and innovative competitors, and demanding customer preferences. Due to these very challenging business conditions, software development is turning towards agile and Scrum methods for its survival and growth. However, IT operational processes are still unable to deliver similar results.

DevOps is a platform that emphasizes refining collaboration amongst the operations and development departments of an organization. DevOps uses several technologies to safeguard a dynamic set-up from a life cycle viewpoint. It is a response to sustain business agility when it comes to IT operations. With a focused ideology, organizations can enable continuous software delivery and join software management and creation together by removing silos. DevOps controls the end-to-end software development lifecycle (SDLC) and focuses on the delivery of software-driven innovation.

It aims to speed up time to market for new applications and helps enhance existing applications. Furthermore, it also serves three essential functions for businesses: 

It promotes communication and collaboration between developers, IT operational experts, and QA personnel.
It automates software delivery and structural variations.
It helps create an agile platform that is faster, smoother, and streamlined.

If we look back into the history of DevOps, we see that it surfaced as a response to Agile software expansion approaches. It was more of a late reply to cloud computing. On the other hand, if we investigate the progress of cloud CRM, we see that it has facilitated change and innovation over time. Cloud CRM has reduced rigid methodological constructs and fuelled innovation. An excellent example of this is the concept of a Scrum, which improves the performance frequency of incremental software releases.

In recent years, CRM software deliveries have increased. This has resulted in a direct impact on the release management process. The operational lifecycle is suffering from a bottleneck as it is not compatible with the increased load of deliveries.

Facing difficulties with CRM? Get a consultation

DevOps and the Agile Software Development Process

For coders, DevOps is pretty much what QA and IT is to the company itself. Perhaps, it is safe to conclude that DevOps and Agile have a synergetic relationship. To explore this relationship, we will investigate the many similarities that Agile and DevOps share:

Both agile and DevOps fuel teamwork amongst versatile and independent teams. The roles may differ, but the key ideology is the same.
Both agile and DevOps promote reiterative and adaptive application approaches and focus on transparency, review, and adaptation. This allows these methodologies to be quality-focused, risk cautious outcomes-oriented.
Agile endorses the continual delivery of progressive software releases. DevOps follows a similar approach when it comes to software operations.

With time, agile methods have created downstream challenges for companies. DevOps offers a solution to these very challenges by streamlining the software creation procedure and allowing for a much faster time to market rate than ever before. DevOps will enable customers to enjoy new software capabilities without process delays. Happy customers are the primary goal of every organization, so that is a big plus!

However, if an organization fails to implement a holistic software ops process to manage agile’s augmented pace, it will suffer much. Problems like a stubborn release method increased errors, and delayed software distribution will occur if an organization is unable to implement software ops properly.

Are there any SLDC challenges you want to overcome? Contact us Today

Scrum and the DevOps Framework

To implement the principals of DevOps in an organization, one needs to follow a systematic approach. Unlike Agile, which has many mature frameworks such as Scrum, Kanban, XP, etc., DevOps does not have a similar design for implementation. Experts have even gone far enough to claim that DevOps can be looked at as a cohesive extension of the agile framework.

The most popular agile methodology of all time has been the Scrum. It has four basic components: roles, events, artifacts, and rules. There are a few simple procedures that allow these components to be naturally extended into the DevOps ideology. We will go over them one by one.

Roles:

The Scrum has three roles that are divided amongst the scrum team: The Product Owner, the ScrumMaster, and the Development Team. DevOps roles can be handled similarly. The team will include QA experts, IT experts, and developers. In most cases, there will be an overlap in the responsibilities assigned to the roles. An essential goal of DevOps is to eliminate the siloes and create integrated software management and developing personnel. Like the Scrum method, the DevOps team should also be independent and goal-oriented. This means that they will have to work with people from different departments to achieve a common end result.

Events/Ceremonies:

Scrum events or ceremonies are based on sprints. A sprint entails four different scrum ceremonies: sprint planning, daily Scrum, sprint review, and sprint retrospective. The same event-based approach can be incorporated into DevOps to reap Scrum benefits such as higher productivity due to improved collaboration and communication, better-quality products, improved team dynamics, and reduced time to market.

Artifacts:

There are three primary artifacts in the Scrum practices: The Product Backlog, the Sprint Backlog, and the Product Increment. These can be implemented in DevOps, for example, through studying the sprint backlog to plan upcoming releases or to evaluate increments to classify variations to the current software ops.

Tools:

Unlike Agile tools, which are generally limited to apps like Jira and Rally, DevOps tools contain a more evolved toolbox known as the toolchain. The toolchain supports numerous operational requirements making it far more sophisticated than the Agile tools.

There are many ways of incorporating toolchains into grouped categories of release, configuration, and operations management. However, for companies that want to implement a toolchain hierarchy in line with ERP systems such as NetSuite or CRM software applications such as Dynamics 365, the following tools may be more beneficial:

Code Tools aid in software development and integration and often assist in the transition towards DevOps. They consist of both integrated development environments and tools specific to applications such as xRM for Dynamics CRM.
Build Tools are used to migrate solution builds between staged environments, for example, migrating Dev to QA. Build tools deal with the source code, code merging, version control, and automated builds. CRM software publishers often advance their own build tools. A good example of this is Lifecycle Services by Microsoft that helps with build management Dynamics 365.
Test Tools are used to determine quality, test security, evaluate performance and scalability of the software.

Release Tools allow continuous integration and deployment of the software. They are utilized for release approvals and automation. They also come in handy in change management scenarios.

On a conclusive note, I would like to add that DevOps integration is highly beneficial and quite necessary for CRM software innovation. A solution provider that can amalgamate DevOps into solutions that it offers, be it CRM or any other practice, will allow enterprises to have a competitive edge through efficient and streamlined internal operations.

Let’s block ads! (Why?)

CRM Software Blog | Dynamics 365

A Practical Guide To DevOps For ERP

May 31, 2020 BI News and Info

Part of the “DevOps for ERP” series

Not so long ago, I regularly had to explain what agile and DevOps meant, but nowadays, people come to us asking how we can help them adopt these approaches.

DevOps, on the other hand, supports application delivery in shorter, more frequent cycles where quality is embedded from the start of the process, and risk is substantially reduced.

What is the practical reality if companies do adopt DevOps for ERP?

Higher-quality development

Low-risk, high cadence delivery

Minimal production impact

The culture question

DevOps benefits and outcomes

Change happens fast, and companies need to respond quickly. IT systems must, therefore, have the flexibility to rapidly change, expand, extend, and adapt.

For more on this topic, please read “How to Build a Business Case for DevOps” and “Self-Assessment: Are You Already Doing ERP DevOps?”

For a practical guide on how to introduce DevOps to your ERP software development and delivery processes, download our e-book.

A version of this article originally appeared on the Basis Technologies blog. This adapted version is republished by permission. Basis Technologies is an SAP silver partner.

Let’s block ads! (Why?)

Digitalist Magazine

Tag Archives: DevOps

VentureBeat

Commentary Competition

DBA “Undersight”

“Bridg-ers”

Transition

Reciprocal Teaching

Molding DBAs

DBA Value Proposition

1. Choose your database strategy wisely.

2. Create a DevOps culture that includes the database team.

3. Get the right tools in place.

4. Prepare the database team for DevOps.

5. Document your databases and data.

6. Get databases into version control.

7. Prepare for data migration.

8. Shift left in your thinking.

9. Automate database operations.

10. Perform ongoing monitoring.

Looking to the future

Summary

Sources

Microsoft Teams, Continuous Collaboration and Integration

Configuring the Azure Pipelines Bot in Microsoft Teams

Release Pipelines

Quality Deployments

Approvals

Deployment Gates

Queries and Alerts

External Integrations

Using Build Pipelines or Release Pipelines

Environments

Environment Security Checks

Scenario: Orchestrating a Release

Automating Release Notes

Azure Application Insights Release Annotations

Using an Azure Function with Web Hooks

Next Steps

Index

Higher-quality development

Low-risk, high cadence delivery

Minimal production impact

The culture question

DevOps benefits and outcomes

Higher-quality development

Low-risk, high cadence delivery

Minimal production impact

The culture question

DevOps benefits and outcomes

Recent Posts

Categories

Archives