devopsy.kinsta.cloud

Tag: software development

  • DevOps: What Do Governments Need to Know?

    DevOps: What Do Governments Need to Know?

    How the government can successfully implement and enforce DevOps practices

    The speed at which technology is being produced it outstripping the pace at which better development tools are being introduced, which makes secure development even more challenging. Unfortunately, the negligence of organizations and authorities is intensifying the issue.

    For this reason, organizations are adopting DevOps. for the betterment of technology. This way technology will be not only safe but also exciting to use.

    The term DevOps is derived from software development (Dev) and information technology operations (Ops), combined to create better results when separate groups work together as one team.

    What Can DevOps Do?

    DevOps has to manage the IT infrastructure as per the necessity of the recommended software code that is dedicated in a composite multi-tenant environment. There is a requirement to have the resources for provisioning, to get the suitable deployment model and also to authorize and monitor the performance.

    When DevOps is discussed, there is a requirement to have constant and incremental adjustments in the code versions so regular testing and deployment are possible. It might not always be feasible for DevOps to do coding from scratch, but they still must understand it.

    DevOps needs to connect several elements of coding and desegregate various segments of SQL data management or messaging tools to release the working software, with operating order and production infrastructure. It could be both the developers who started into operations and the system administrators who started into the coding domain. Either way, there is a cross-connection work function that is seeing a massive upside in the style of software that is produced and used in mission-critical applications.

    How Can DevOps Be Enforced Successfully?

    Now that we have discussed what DevOps do, it’s time to learn the ways in which organizations enforce DevOps successfully.

    Higher Authority

    It is essential that we refer to higher authorities. By getting support from the top authorities, we can easily manage the work of DevOps.

    “DevOps is fundamentally a reorganization.”

    –Adrian Cockroft, lead architect, Netflix

    Altering any management organization, with its deeply rooted techniques of functioning and complicated network of employees and suppliers, is a challenging job. So, solid backing at the beginning is as crucial as having employees. You cannot start a new technique without employee support; in the same way, you cannot begin a new plan without any support from authorities. You need someone from the top to monitor the work and provide feedback.

    Blameless Postmortem

    Adopting DevOps also requires every member of the team be comfortable in their learning. Hence, the blameless postmortem, which eliminates finger-pointing when things go wrong—highly recommended for DevOps beginners. Blameless postmortems are even required by some government offices.

    Blameless postmortems organize a cross-section of those invested in the project to evaluate why certain outcomes occurred. The postmortems include an examination of the situation and ways to resolve them through various procedures or technology variations. They are an excellent method to initiate constant development.

    Increase DevOps Engineers

    Another effective way of expanding DevOps and enforcing it in the government is through hiring DevOps engineers. A DevOps engineer is the individual responsible for all the steps during the process of DevOps, and are responsible for bringing both organizations together to work as a team. There are not enough DevOps engineers today and the workload is much more than they can handle.

    Start Small and Scale Up

    Whenever you start something new, start on a smaller scale. Whether you’re working on a business plan or testing a new recipe, you should always start small and work your way up.

    In the same vein, it is important to start small when implementing DevOps. Rather than go all-in at once, create a group of people who will work together as a team. If the results are good enough, then expand your implementations to a wider audience.

    Eliminate Restrictions

    Last but not least, it is essential to remove all the constraints involved. Eliminate any limitation that may occur during DevOps enforcement. Limitations could vary from generating new constructions or applying code variations to assimilating data foundations. If the constraints are not removed from the beginning, it may cause problems afterward.

    Conclusion

    With the expansion of equipment and expertise, new practices are introduced in the government. If applied properly, these practices could generate pleasant outcomes. DevOps, which brings together two forces for effective results, is one such practice.

    — Zehra Ali

  • Best Practices for DevOps in the Cloud

    Best Practices for DevOps in the Cloud

    DevOps is commonly defined as a methodology that combines software development with IT operations. The goal is to shorten a system’s development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives. Putting DevOps into practice is an ongoing experiment for many organizations.

    Developers often struggle with continuous integration (CI) or continuous delivery (CD) performance, testing delays and other bottlenecks. In fact, one survey reported that only 34% of projects finish on time and only 42% come in on budget. Security and development teams must collaborate to keep up with the rapid development life cycle without sacrificing security with every update.

    Enterprise SaaS apps are not distributed like traditional software—they are continuously running services. So, CD is all about updating the service with a set of changes. In public clouds such as AWS and Heroku, this is done through pipeline stages (e.g. dev, test, staging and production). In platforms such as Salesforce, stages become sandbox environments, ephemeral scratch orgs and production instances.

    How can development teams shorten the development life cycle without sacrificing the integrity of the features and updates? In this article you will learn key DevOps practices to achieve predictable, reliable release management.

    Advanced Planning Ensures All Boxes Are Checked

    Agile planning is now de rigueur for enterprise development. It is best used if:

    • The product itself will most benefit from flexibility.
    • Regular face-to-face interactions and collaborations are needed between team members.
    • The end product requires regular updating, monitoring and continuous delivery to the client throughout the life cycle.

    For CD, ensure your user stories are sized correctly and that each story rolls up to an Epic that represents a standalone feature. This enables your team to release bite-sized pieces of functionality that are consumable by users and traceable back to your release plan. Also, define acceptance criteria for use in the verify stage so you know when something is done-done.

    Manage the Source Code, Especially When Working in a Shared Environment

    There are a few practices of app creation that impact CD. First, source code is not the only element of an enterprise solution. Schema, user interface, access control rights and static resources such as icons and images are all part of the creation process and should be managed just as diligently as source code. They should all be checked in to a version control system (VCS) as a single source of truth.

    Second, ensure that developers are making changes in a segregated environment. In some low code platforms, such as Salesforce.com, this becomes a challenge, but even in a database, multiple database administrations (DBAs) can step on each other’s changes when working in a shared environment.

    Functional Testing

    Automated quality processes are difficult to implement, but essential Selenium is a great tool for testing functionality and should be part of your DevOps practice. But there are several verifications that should be made before you get to functional testing. Static code analysis tools, such as PMD, are essential to ensure your development team is coding against a single style.

    Define a team style and enforce its use. Unit test coverage is also essential—incorporate them with a coverage of at least 75%. Finally, after these automated tests pass, implement a manual peer review. Old hands are able to spot opportunities for performance improvement where automated tools may not.

    Changes Should be Released in a Defined Pipeline with Strict Quality Gates

    Packaging for CD is about capturing changes that can be incrementally released into the next stage or environment. Development teams should dedicate a branch for each stage and bundle incremental changes into a promotional branch to leverage the merge conflict detection in your VCS.

    Changes should be released in a defined pipeline with strict quality gates that ensure the verification steps and enforce the order of release stages. Developers should not be able to bypass key stages throughout the development cycle—for example, moving from development to production.

    Focus on making smaller changes, which result in reliable, predictable releases. Finally, be sure to automate promotions. This enables your team to validate the promotion scripts in integration, test and staging before releasing to production, which decreases the likelihood of an unhappy surprise.

    Automate Configuration, Especially for End User Access Rights

    Make testing for proper configuration part of your verification process. Platforms such as Salesforce have powerful profiles and permission sets that enable user access to only the right information. Improper configuration can expose personally identifiable information (PII), credit card numbers or medical health data.

    Monitor for More Than Just Service Availability and Performance

    Most SaaS companies monitor service availability and performance. But excellent companies also monitor data access to detect improper configuration changes and monitor end user feature usage, which gives product managers visibility to their usage.

    — David Brooks

  • ‘DevOoops’ Moves: Unforeseen Lock-Outs

    ‘DevOoops’ Moves: Unforeseen Lock-Outs

    DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by Carlos Sanchez, principal software engineer, about unforeseen lock-outs.

    Scenario:

    When you’re automating deployments using configuration as code, make sure you have the right protections in place (i.e., validation of configuration). Otherwise, it’s easy to lock yourself out, forcing yourself to manually log in to each machine to fix it when a bad change is pushed and deployed to all the machines.

    Having a strong technology solution that securely and centrally stores credentials for the names of people who access those machines is critical to maintaining a successful DevOps program. It’s a no-brainer. When you have to service accounts, you’re much more likely to be able to leverage a fast-acting script to log in and reconcile logouts if credentials are centrally stored than if you had eight individually managed service account-based credentials.

    How do you reconcile lock-outs? How do you avoid the kind of DevOoops situation that can derail all of the good progress you’re making? The process you adopt will depend on what your software development and deployment life cycles look like. Here are several potential approaches:

    • You can use multiple staging and preproduction environments that share common configurations with the production environment. This sets up a process where, before you try to deploy an app or a new configuration to your production environment, you know you have successfully deployed it to environments that are as close as possible to production, multiple times.
    • You can have post-deployment validation scripts run after every deployment and have them validate things such as, Can account X log into environment Y? The scripts should include common or leading indicators of success or failure of a deployment. Once artifacts have been deployed and the system starts, every deployment will immediately run these scripts as part of the deployment process. So, every part of the deployment is automatically validated as success or failure.

    When taking an approach such as rolling deployments, you also need to ensure that broken configurations are identified before they’re propagated across multiple servers or server clusters. This means you need to validate your deployment and your configuration changes before you go to production, validate deployment and configuration changes on first deployment and then validate, validate, validate at each subsequent step.

    By doing all of this, you avoid surprises. You extend a quality-first, continuous validation approach beyond just your application code and apply that to your environment. Avoiding unnecessary lock-outs will help you mitigate risk, eliminate wasted time and avoid bad customer experiences.

    Takeaways

    • As you bake quality into the processes and shift automation left, you need to make sure you validate all changes early and often.
    • Organizations need to implement proper processes, not only for application code changes but also for infrastructure as code changes that manage environments.
    • In automating in pursuit of DevOps, it’s necessary to have a strategy for credentials and secrets management of permissions for your DevOps and production systems.

    — Brian Dawson

  • Different Organizations, Different DevOps Outcomes

    Different Organizations, Different DevOps Outcomes

    The main motivation behind inventing DevOps platform was to help close collaboration between developers and IT operations. Basically, DevOps emerged as a great platform to bring closer together developers and beneficiaries of the app development process. DevOps initiates a cross-disciplinary practice spanning across development and operations.

    The ultimate benefit of the DevOps approach is removing the barrier between development and deployment of software applications in specific business processes. Regardless, not all businesses reap the benefits of DevOps platform.

    Does DevOps really suit all businesses of different sizes and niches? What are the key considerations for utilizing DevOps platform? These are the questions we will try to answer through this article.

    Do All Businesses Require DevOps?

    The common and widespread consensus is that any software development company geared for innovation must embrace a DevOps environment. Any business that considers innovation and smooth deployment in the software development process—a key factor in their long-term growth strategy—should take advantage of the benefits of a DevOps platform. Whenever any service provider needs to adopt new strategies to keep pace with the evolution in the software space, DevOps will come as an irreplaceable platform choice.

    Despite this consensus and widely accepted perception, there are different opinions in the market. Many industry experts believe that to reap the benefit of the platform you need to have a dedicated DevOps team in place. If you have a DevOps culture and in-house DevOps team in your company, you can gain a competitive advantage.

    The Key Benefits of DevOps

    The main benefit of DevOps is faster delivery of software with much-improved quality. There can be several other benefits depending on the industry.

    While some companies refer to the huge reduction in downtime since they adopted DevOps culture, there are still many others who simply give credit to the platform because of its integrated approach that makes the process more agile and fast-paced.

    For most companies, the domino effect of getting better software at a faster speed ends up delivering sustainable growth and revenue opportunities.

    Here’s a look at the role of DevOps platform across three types of businesses: small companies and startups, midsize companies and large business houses.

    Small Companies and Startups

    In smaller companies and startups where resources and human capital remain under-supplied, the responsibilities ascribed to developers, engineers and deployment professionals often tend to get blurred or overlap. Because of the scarcity of human resource, developers and engineers are often assigned multiple responsibilities. Naturally, in such companies, it is common to see cross-functional teams ready to engage into various development projects with ease. This makes them ideal business organizations to embrace and grow with DevOps culture.

    Midsize Companies

    As the companies tend to grow bigger in size and resources, they have a bigger (and often unbreachable) divide between verticals such as operations and development. In such organizations, staff are less likely to be open to cross-functional responsibilities, as many have been in the same job doing the same tasks and feel settled. This brings in a stagnant organizational process, where strong departmental divide rules the business process outcome.

    This stagnant work culture makes such companies less appropriate candidates to implement DevOps environment. For these companies to reap the benefits of a DevOps platform, mass organizational changes should be brought in the team structure. Building a separate cross-functional DevOps team to handle some focus projects can also be good practice for them.

    Large Companies

    Large companies enjoy the luxury and abundance of resources, and this makes them much better-placed compared to other organizations. Companies such as Amazon, Facebook, Google and Microsoft have the diversity, huge experience and robust abilities to bring together cross-functional specialists from development and operations to work on ambitious projects. These organizations are known for having product-oriented units, comprising specialists from both development and operations.

    Apart from their cross-functional expertise, product-focused approach and abundance of resources to roll on new projects, large companies also can make a big difference to the teamwork and motivation through a highly unified vision and strategic long-term objectives shared by every member of each team. This is why large companies always stand as suitable candidates to embrace DevOps approach and environment for their projects.

    Fixing the Right DevOps Strategy: 3 Things to Consider

    Beyond the organizational differences and core strengths and weakness for embracing a cross-functional DevOps approach, we must look into the key aspects that make a right strategy for any organization to incorporate DevOps into their scheme of things. Question is, despite the shortcomings and lacking, how can you embrace DevOps environment and reap the benefits? Here we provide some clues:

    • Making Change a Habit. Some strategists believe that any organizational change will face a lot of friction, causing substantial harm to the immediate business outcome. But there should be no reluctance to change for this. Rather, by bringing constant changes, people get used to the friction and pain and it becomes normal. This is one way to replace traditional IT mindset with DevOps.
    • Starting Small with a Neat Team. Obviously, finding the appropriate and credible skilled employee for your DevOps projects is not always easy. This is why it is advisable to create small startups or units, in which sharing the common vision and embracing a cross-functional approach becomes the order of the day. On top of that, do your best to bring out the best from your team and hire some experienced ones with knowledge of DevOps.
    • Continuous Development Mindset. We all know how the DevOps platform always focuses on continuous development approach. It is easier for the software developers to embrace such approach, but for operations staff, you have to slowly make them think of infrastructure as evolving and slowly building components. That’s something challenging but not impossible.

    Conclusion

    DevOps has emerged as the most promising development approach for modern software developers. Though for many development companies the friction emanating from strict role divides is becoming an obstacle, the positive push by DevOps for cross-functional approach looks indomitable.

    — Atman Rathod

  • What Building a March Madness Bracket Teaches About DevOps

    What Building a March Madness Bracket Teaches About DevOps

    Applying the lessons learned from the NCAA tournament to DevOps in your organization.

    ‘Tis the season for filling out brackets, secretly checking your favorite team’s livestream at work and watching your ranking rise and fall in the office pool.

    Unless you’re this guy, your bracket is already busted. However, there’s always hope for next year, especially if you pay attention to five key indicators that experts say predict the success of teams in the NCAA championship.

    But you don’t have to wait until 2020 to put these tips into action. In fact, carefully constructing a March Madness bracket can actually teach you a lot about DevOps.

    The following five tips can be applied to your next bracket, as well as your software development team:

    Don’t Rely on Offense Alone

    A great offense is key to scoring, but the gap between offensive and defensive efficiency can make all the difference when it comes to a team’s chance at the championship. Over the last 17 years, only one national champion didn’t finish in the top 20 for both offensive and defensive efficiency. Similarly, software teams have to rely on multiple team members including the programmers focusing on new features and fast plays, as well as the QA and operations teams ensuring that there are measures of testing and monitoring in place, so those same features aren’t released with bugs and breakages. To be successful, you need to aim for a balance of speed and quality. In DevOps, your efforts will fall short if you’re only thinking about your offensive strategy while underestimating the importance of strategic defensive plays.

    Coaching is Crucial

    Coaching experience has become a strong predictor of future success, as 15 of the last 17 NCAA title champions were led by a coach who had been to the Final Four previously. Similarly, leadership and management in DevOps and the transition to DevOps is paramount to creating an environment that is supportive of the necessary changes. In fact, according to a Forbes Insights and PMI survey, 85 percent of respondents said that change management is critical to their success in times of disruption. As teams attempt to speed up their processes to meet consumer demands, it’s evident that leadership is going to be a defining factor of the success of the team. Additionally, amid a cultural shift, management needs to have the right mindset to get the entire team on board, adopting new tools and practices. Just as coaching influences college basketball, experience, skill and vision all come together for transforming a team and creating a culture of DevOps.

    Expect Upsets

    Upsets happen—that’s the beauty of March Madness! While teams are seeded to indicate the likelihood of success in the NCAA tournament, you might think that it’s always best to pick the highest seed. But according to the NCAA, you should be aiming for around 16 upsets in your bracket. Just ask anyone who had UVA in their Final Four last year, when the No. 1 seeded team lost to 16-seed UMBC, how important it is to expect an upset. Sometimes, all your systems are perfectly in place and everything is performing as it should, and something will still break. What’s more important than aiming for perfect software delivery is having the processes in place to patch bugs, handle downtime and fix errors when they inevitably occur.

    Teamwork Will Tell You Everything

    There’s always talk of the star players, but success comes down to much more than one person’s free throw percentage, shooting efficiency and steal rates. Most of the statistics you look at to build your bracket revolve around teamwork—the team’s strength of schedule, the team’s winning streak, the team’s loss margin, even the measurement of explosiveness and competitiveness. None of these points can be attributed to one person; they change from season to season, and they’re all about how the entire team works together. Selection Sunday is needed every year to seed the teams because performance changes every year based on the team dynamic. Similarly, your organization will not be successful in DevOps if there is not a focus on communication, collaboration and teamwork.

    The Absence of Key Players Will Trip You Up

    While you can’t depend on one star player to determine the outcome of an entire team, you’ll also run into trouble if key players are out for the season. Just think: You probably wouldn’t pick Duke to win as quickly without Zion Williamson. Just the same, when there are key teams and team members missing or not committed to a changing culture, it will hinder others. There are various roles that every organization needs to succeed in DevOps, and this requires everyone to be on the same page whether you’re in development, operations, QA or are a business stakeholder. People are one of the most important parts of the transition to DevOps; if the entire team doesn’t show up, new technology and approaches won’t be able to make up for it.

    There’s a strategy to everything, and it just so happens that your approach to DevOps may be similar to your approach to filling out your bracket.

    By following these five pieces of advice, your software team will be more prepared to win it all when it comes to attaining a faster delivery of high-quality products.

    — Alexandra McPeak

  • Dev and Ops: Not from Different Planets

    Dev and Ops: Not from Different Planets

    At a conference, I heard a speaker remark that “Dev people are from Mars while Ops people are from Venus.” That’s catchy and captures what a fair number of managers believe instinctively. But is it really true? I’m not convinced.

    We all know that DevOps enables us to deliver software faster, with fewer bugs and much less downtime than traditional approaches. But DevOps is new, complex and often challenging for teams to embrace. Developers often guard their tools and operations shake their head each time they hear about some new asset bundling package they have to support. I think the first few meetings of Dev and Ops probably do a lot to build the notion that they are from different planets.

    In my experience, however, the opposite is true. To borrow a different popular catchphrase, they are more “brothers (or sisters) from a different mother.” When you examine the makeup of Dev and Ops people, you find more similarities than differences. Here are some examples of their common ground:

    • Consistency and Standards. Both Dev and Ops are technical endeavors that place a huge premium on things being “precisely” correct. Whether coding a service or setting up an AWS instance, “in the ballpark” doesn’t cut it. For this reason, both camps try to establish standards for how they work. Whether keeping Dev teams all using the same environment or Ops trying to keep Dev, testing and products all running the same, both need to benefit from building consistent environments.
    • Coding Skills. Whether coding or scripting, Devs and modern Ops teams need to be comfortable in a variety of highly technical tools. Build scripts, deployment, automated testing and reporting all require some coding skill.
    • Common Tools. If you look at the DevOps ecosystem, you’ll increasingly see tools that are intended for both Dev and Ops tasks. Dev people, for example, use Git for reusable code; Ops uses Git as well for configuration of things such as Docker. Also, Dev uses Jira to track bugs while Ops uses Jira to track tasks.
    • Shared Metrics. While their focus may be different (code versus pipeline), both Dev and Ops share many metrics of success—consistent delivery, fewer errors, responsiveness to customers and uptime, to name a few.
    • Test-Driven. Dev and Ops both embrace the “fail fast” mantra. They want to know if a change will break anything as soon as possible, long before it ever impacts a customer. Both often start with automated tests, which are run on Dev or local instances, to verify the changes are non-breaking.
    • Love of Automation. Neither Dev nor Ops enjoy manual, error-prone work. Both gravitate to tools that automate routine tasks, reducing variances and errors.
    • Star Wars. Finally, both groups are avid “Star Wars” fans. Just watch how they open automatic doors using the force or name servers or other things with sly “Star Wars” references (such as “Secret Rebel Base”). In fact, next time you’re in a DevOps meeting and somebody is wondering if Dev and Ops can get along, bring up Jar Jar Binks and marvel at the immediate—there will be a completely concordant reaction from both sides.

    So, are Dev and Ops from different planets? I don’t think so. I see Dev and Ops as being like those twins separated at birth, who, when reunited decades later, laugh the same, have the same twitches and both married spouses with the same first name. And in the best DevOps shops I have seen, that’s a really good thing.

    — Joshua Platt

  • SauceCon Speaker Profile: Phil Wells

    SauceCon Speaker Profile: Phil Wells

    This is the seventh in a series of articles highlighting speakers at SauceCon 2019. SauceCon brings together the global community of Sauce Labs users and continuous testing experts to learn from each other and level up their automated testing and continuous delivery skills. This year’s event will be held April 23-25 in Austin, Texas.

    Phil Wells is coming to SauceCon 2019 to talk about the New York Times Crossword.

    No, really, Phil is a software engineer with the web group of the New York Times Games team whose job is to build quality into the online version of the famous puzzle done by thousands of people daily.

    More than anything, Phil cares about mission. During his 12 years of web development experience, he has worked on software that educates parents of kids with autism, software that helps people perform better on standardized tests and now for the New York Times, whose mission is to help people understand the world around them.

    “The puzzle brings so much joy into people’s days,” says Phil. “I’m really proud of my work.”

    When Phil tells people what he does for a living, they want to know what it means. Does he just solve crosswords all day? Is he in web development or game development? Does he know Will Shortz? (The answer to that last one is no, but he is an emoji in their internal Slack instance!) People love the crossword, and they all seem to want to know more about how the sausage is made.

    Phil’s session at SauceCon will be all about “Automating the New York Times Crossword.” He wants to show test practitioners that testing a web application as complex as the crossword involves the same best practices as testing anything else. During his talk, Phil will show attendees some of the tricks his team used to become fast and reliable.

    “The main theme of my talk is about making software development feel better. We don’t want to feel the shame of failed builds or delayed releases,” he said. “So, we built these systems to help us ship the stuff we build quickly and safely.” The first half of his talk covers the things the team did to get cultural wins internally. In the second half, Phil will dive into his particular team’s bag of tricks; the tools they use to make sure the tests are making everyone do their job better.

    When he’s not working on testing the crossword, Phil enjoys improv comedy. He is also an aficionado of “The Big Lebowski,” and has written a book called “Dudesong,” an epic poem adaptation of the movie, featuring 5,500 lines of poetry in rhyming couplets!

    Whether or not you’re a fan of “The Big Lebowski,” you can hear from Phil and more than 30 other expert speakers at SauceCon 2019, the third-annual Sauce Labs user conference. To see a full list of presentations or to register, visit the SauceCon website.

    — Rebecca Cramer

  • Tech, Legislative Changes Impacting Developers in 2019

    Tech, Legislative Changes Impacting Developers in 2019

    In 2018, software development saw exponential growth in areas including blockchain technology and artificial intelligence, and the New Year has the potential to bring even more change through recent developments in automation, cybersecurity and legislation.

    Software development professionals have a unique opportunity to leverage these new developments this year, and the first step in doing so is learning how their industry has been impacted.

    Automation is undeniably looked at as an integral part of a software developer’s workflow. From using it to avoid repeat coding to stress-testing for systems, automation holds an incredibly valuable place in a developer’s world. In fact, recent data has shown that the percentage of development teams not automating has dropped by more than 50 percent in the last two years, and teams that fully apply continuous integration (CI) now outnumber those that don’t.

    One key development that will carry forward into the New Year is the integration of DevOps with the cloud. Cloud-integrated DevOps “can create a bug report, generate script, perform calculations and test code,” according to an article by CIO Applications.

    Effectively Automating Results

    The last year in automation also brought forth innovative artificial intelligence (AI) programming tools that use machine-learning algorithms to generate code using codebases developed by humans, as well as robotic process automation being used as a development platform for AI-driven apps.

    Automation isn’t the only area that software developers should focus on in 2019. Businesses around the world are falling victim to cyberattacks of all shapes and sizes. With advancements in technologies, these attacks are being more sophisticated and leading to breaches that at the most can cripple companies to the point of extinction and at the least create a serious scarring of consumer trust. According to the Poneman Institute’s 2018 “Cost of a Data Breach” study for IBM, the average cost of a data breach for a U.S. company stands at a whopping $7.91 million.

    With the advent of the internet of things (IoT), and the United States now being the No. 1 target globally for cyberattacks, software developers have the ability to help combat these devastating crimes. And, although developers can be the ones to lead the charge to help businesses utilize more effective cybersecurity mechanisms, the world of software development has its own vulnerabilities that cybercriminals have taken advantage of.

    Making Safety the Priority

    The truth is that nobody is safe from a cyberattack. Even behemoth companies that deal with tech and software development,  such as Facebook, have fallen victim to attack because of a lack of prioritizing cybersecurity. Effective security protocols can include using the cloud during the development process, along with having an awareness of the level of sensitivity of the data you’re handling and protecting that data accordingly.

    Furthermore, companies are now strengthening their cybersecurity efforts during the software development process by making a space for both the development and security teams to work together.

    “These organizations are able to innovate faster, save costs and become more agile in dealing with news risks,” said Chris Wysopal, chief technology officer at Veracode and Forbes contributor. “It all starts with recognition from business leaders that integrating security into their development processes is important.”

    Policies for the Benefit of Tech

    Not only can software developers benefit from creating avenues to work in automation and cybersecurity, but taking advantage of policies coming out of Capitol Hill can also prove to help improve performance and business opportunities.

    The Tax Cut and Jobs Act of 2017, which impacts tax years after Dec. 31, 2017, offers benefits for tech organizations that ultimately can create what agile companies need most: extra funds to put back into their business. Besides the enormous benefit for tech giants of overseas cash being taxed at only 15.5 percent, small- to midsize companies involved with tech can take advantage of the R&D Tax Credit.

    This government incentive is particularly noteworthy for those in software development who are either building out and testing new software or improving existing software, as the IRS has viewed these activities as qualifying for the credit.

    Whether developers are breaking new ground using automation or AI, the credit is an invaluable tool for a businesses looking for more money to put toward new technologies.

    The realm of software development, with increasing competition and constantly advancing technologies, isn’t the easiest field to thrive in. However, taking into account these developments and how they have impacted the industry can be the first step in seeing stronger performance in 2019.

    This article was co-authored by Rizwan Virani, Senior Vice President in alliantgroup’s Houston national office. He oversees alliantgroup’s Energy Incentives practice. Rizwan is an experienced electrical engineer with prior experience in the semiconductor industry. He brings several years of experience and expertise in manufacturing technology, semiconductor process, electrical and mechanical hardware development and fundamental engineering principals. Prior to joining alliantgroup, Rizwan was a project engineer and consultant for one of the largest semiconductor capital equipment makers.

    — Rick Lazio

  • Feature Flagging Poised for Wider Adoption

    Feature Flagging Poised for Wider Adoption

    Feature flags, also known as feature toggles, provide a means for DevOps teams to test and add new capabilities to their applications without having to take the entire application offline. The downside is they generally result in more branches of applications that need to be carefully managed within the context of a DevOps process.

    A recent survey of 550 software developers and decision-makers conducted by the market research firm Vanson Bourne on behalf of Atlassian and Rollout.io, a provider of a platform for managing feature flags, suggests that IT organizations are getting more comfortable with managing feature flags.

    The survey finds 95 percent of survey respondents said their organizations have implemented, have begun implementing or plan to implement features flags. Those that have implemented feature flags said they add 30 new features on average to each application per year, compared to those that have only begun implementing (21) or plan to implement (18) them. A full 81 percent said use of feature flags will increase over the next 12 months, and 88 percent said modern software development should assume to include feature flagging.

    The primary driver for implementing feature flags are a need to reduce risk (46 percent), increase speed of development (46 percent) and increase speed of deployment (45 percent). Eighty-seven percent of respondents said enabling an on/off or “kill” switch for features also reduces the risk of application downtime for customers.

    A total of 97 percent of respondents said they are under pressure implement new application features faster, and yet 65 percent said it is difficult to accomplish that goal safely. More than 61 percent of respondents said their organization releases new versions or updates for applications once a week or more. However, 72 percent admitted they have lost customers or users due to application development errors.

    Rollout COO Ronit Belson said building out the functions required to manage feature flags doesn’t make much sense when platforms such as Rollout.io are now emerging. The survey finds nearly 90 percent of respondents who have implemented feature flags in-house would consider moving to a third-party supplier for feature flagging management software. A total of 37 percent of respondents said the cost of in-house development is higher and 32 percent said they encountered more complexity than anticipated.

    Belson added most organizations not only fail to appreciate the cost of implementing feature flagging on their own, but also the impact feature flagging has on the culture of the IT department.

    Thanks to the rise of microservices, feature flagging should become more prevalent as monolithic applications give way to a more granular approach to application development that makes it easier to isolate functionality. In fact, the ability to apply feature flagging might be considered one of the primary benefits of the agility inherent to any microservices architecture, especially it if relies on containers that can be easily ripped and replaced. The challenge organizations will face is implementing the DevOps processes required to embrace feature flagging at scale.

    — Mike Vizard

  • Crowdsourcing, Data Science Top Talks at the 2018 Topcoder Open

    Crowdsourcing, Data Science Top Talks at the 2018 Topcoder Open

    The 2018 Topcoder Open (TCO), the world’s ultimate programming and design tournament, took place in Dallas Nov. 13-16 and featured the best technologists from around the globe competing for cash prizes and international rank. Companies of all sizes shared perspectives on digital transformation and caught a glimpse of the most coveted programmers on the planet. A handful even provided current software development challenges their in-house IT teams face for Topcoder Community members to solve.

    I caught up with Dave Messinger, chief architect of Topcoder, for his take on why 2018 brought one of Topcoder’s most challenging tournaments.

    Jessie D’Amato Ford: What’s your history with Topcoder?

    Dave Messinger: I’ve been with Topcoder since December 2001. It’s a fast-paced, innovative environment that thrives on creativity and speed, which mirrors the spirit of our unequaled Topcoder Community members. Today I run Topcoder’s technology platform, which is the core of our crowdsourced software development work with enterprise customers.

    Ford: What were a few highlights from the 2018 TCO?

    Messinger: This was Topcoder’s 17th annual event and it was especially competitive. We had 100+ finalists from 34 countries, with first-time competitors coming from Morocco, Hungary and Nicaragua. Topcoder ran 1,600+ challenges and awarded more than $2.5 million in prize money. The companies attending were impressed by not only the caliber of technologists competing and how much they accomplished in such a short period of time, but also at the efficiency, accuracy and speed of crowdsourced software development.

    Ford: Tell us about one finalist you kept an eye on while at the TCO?

    Messinger: Thomas Kranitsas (Topcoder handle: thomaskranitsas), from Greece, graduated from school and served in the Greek Air Force. Now in his third year as a Topcoder Member, thmaskranitsas has been a Code Review and Copilot on crowdsourced software development projects for companies. He sees Topcoder as an opportunity to work with the newest technologies, solve real-world business problems, earn money and meet the “best developers and designers in the world.” He finished 5th in the TCO’s First2Finish competition, with only 4.55 points separating him from the winner.

    Ford: How has crowdsourcing changing the way software is developed?

    Messinger: When Topcoder first opened its doors, the skepticism surrounding crowdsourced IT was overwhelming. Like many technology innovations, crowdsourcing had an uphill battle. It was a completely new way of developing software and managing teams—it, too, changed for the better over time. Fast forward to 2018 and now crowdsourcing is mainstream. The internet and cloud computing helped democratize development by allowing anyone in the world to access to the same resources and become familiar with multiple platforms. Other technology advancements and techniques, like microservices and DevOps, have also allowed more developers, designers and data scientists to collaborate on software projects with little ramp up time, which reduces costs and increases efficiency (both important to global organizations).

    Ford: What industries have been quick to catch on and why?

    Messinger: Topcoder has customers in almost every vertical imaginable because the methodology for developing high-quality software with a crowdsourced model is applicable to anyone. Crowdsourcing works best when developers can easily access SDKs, APIs and development environments. The 1.4 million (and growing) Topcoder Member Community has been working on projects that drive significant industry change.

    Ford: How does the TCO recognize and reward Topcoder Members?

    Messinger: There are multiple rounds to champion before Topcoder Members earn a finalist spot at the TCO in the U.S. (and we’ll fly the finalists in from wherever they are in the world). The collective intelligence in one place is astounding! It’s also a great opportunity for technologists and companies to pick up new software development techniques, as well as discuss the latest trends. Topcoder Members are passionate about helping businesses solve IT challenges.

    Ford: What skills are companies looking for in today’s developers?

    Messinger: Companies are not only looking for the best developers, but also for those who can clearly document code and collaborate well with the rest of the team. Topcoder’s viral nature and crowdsourcing methodologies hone in on those skills no matter where someone is working.

    Ford: What’s ahead for The Topcoder Open in 2019?

    Messinger: 2018 marked Topcoder’s first use of automated testing as part of our TCO development track and we’ll be expanding it in the future. TCO 2019 will bring Topcoder’s first test-a-thon competition: our QA community will participate in a live QA challenge to identify bugs in live tournament style. It will be exciting, for us and the Community, as well as companies watching these master technologists at work.

    — Jessie Ford