DevOps

Connect KeyNote with Brian Harry. Devops Projects – awesome scaffolding for your release management project!

Still going through videos from Connect, there’s a lot of stuff to wade through! Definitely enjoyed Brian Harry’s keynote address – especially the awesome Abel Wang helping out as copresenter. Here’s my notes.

The takeaway stuff is this –

  1. you can use Azure DevOps Projects to create a fully functional CI/CD pipeline as a starting point to any project, then extend it. This is way cool and I can’t believe it hasn’t existed before. The release visualizations are definitely top knotch.
  2. YAML is now supported. (Several of my customers have been asking about this!)
  3. There’s some real goodies here about how Microsoft handles its releases – hint its not Dev-> Prod with one click, using scale units.
  4. Automated gateways are now possible in VSTS. This is definitely a huge win…

In more detail:

  • (roughly 1 min in) – Food for thought: “DevOps is all about shortening feedback lops… automated deployments are often the first thing we think about.” There’s a lot of plumbing though – it can be daunting.
  • (minutes into broadcast) 4:30 – Azure DevOps Projects- easily create a full end to end RM pipeline, using Node.Js, .Net, Java, PHP, Python.
  • 5:59 – dashboarding – click on links for code / build/dev pipeline. To customize, clone it onto your HD – delete all files, copy in your code, then push it back to VSTS using Git. Easy!

  • 13:44 – YAML support now included in our CI system
  • 14:41 – No one actually pushes a button and code goes out the door to production – “I call that the fastest way of deploying bugs to your customers.” At Microsoft we have 15-20 different scale units (subsets of customers). We use Release Management to gradually roll these out across environments. First we roll out to one scale unit, watch twitter for sentiment downturns, check feedback, use it – etc. Then we wait 24 hours before deploying to the next ring. That’s responsible CI/CD. If we have a blocking bug – we pull the cord and roll back.
  • 23:00 – demo of build agents running natively on all 3 platforms – Win/Linux/Mac. You could use one release to all 3 environments if you wanted to. I thought this was amazing:

  • 26:18 – automated gate creation. These are automatically created post deployment monitors – using Azure monitor, functions, REST API, and service bus to stress test/check your new system’s health.

  • 27:48 – creating a YAML build
  • 32:27 – fork into private repo vs a branch.

 

For a full writeup including a new walkthrough on Azure DevOps Projects, click here. There’s a quickstart here.

Full list of Connect DevOps vids and my writeups: (this will grow)

 

Advertisements

DevOps – how we do it at Microsoft, with Aaron Bjork.

Two great interviews I found today and enjoyed very much, between Donovan Brown and Aaron Bjork (who is head of the DevOps part of VSTS).

From the first video:

  • We treat our development teams as adults – “I’ll trust you until you give me reason not to.”
  • How does Microsoft structure their product teams?
  • How do we keep to a consistent UI? i.e. checkboxes versus radio buttons – what design guidelines do we use?
  • How to tie together 50 teams with one weekly meeting of six people
  • How big of an advantage it is to dogfood it – be your own first customer.
  • “Our engineers write code, test code, and deploy code.”
  • Feature flags – we don’t use these for just one customer. The boundary to turn on the flag is during the current sprint, and then turn off the following sprint.

Second video notes:

  • (minutes into program) 1:27 – Why 3 week sprints? Goldilocks principle. Donovan mentions a physician product owner where 4 weeks was the best he could get.
  • 5:46 – Dogfooding, and customer driven features.
  • 13:09 – We used to have all these plans that helped me sleep at night – but did we ever ship on time? (i.e. waterfall and requirements planning as a security blanket)
  • 16:32 – importance of monitoring. DevOps is not automation. Most of their DevOps discussions end with Agile.
  • 19:03 – distrust between Dev and Ops. The chasm grows. Now we are improving with TDD, unit testing – but the distrust is still there.
  • 20:27 – treat your deployment pipeline as a feature of your product.
  • 27:54 – Do we deliver mid-sprint at Msft?
  • 32:57 – “You can’t cheat shipping.” Scenarios, features, stories and tasks.
  • 39:10 – Feature flag litter and documentation.

DevOps – are you stuck on where to start? Building out 4 Release Pipelines in an Hour with Donovan Brown

Such, SUCH a great treat having Donovan come all the way from Houston for this presentation. He’s a fantastic presenter and his hands-on knowledge blows my socks off. I can’t thank him enough for making the trip.

IF YOU ATTENDED and you enjoyed the presentation – or even if you didn’t enjoy it – WE NEED YOUR HELP!
Take a few minutes and click on this link – it will tell us how we can improve next time, and hopefully lay the groundwork for Donovan to come back in a year or so.

There’s a streaming video available here of Donovan’s Portland Area .NET User Group (PADNUG) presentation. It was outstanding! If you want to see one CI/CD release pipeline built out releasing a website to Azure in one hour – well sorry, that is not what he did. Instead, Donovan built out FOUR pipelines in an hour – using Node.js, Java, .Net and .Net Core., while describing step by step what he was doing and why – using VSTS, the Azure Portal, Visual Studio, and a cool command-line tool I hadn’t heard about called Yo Team!

The key takeaways from his presentation are as follows:

  • If you only get one thing from our time together – Microsoft is for any language, any platform.
  • Licensing costs should not be a blocker for us. It’s like $10/person per month, and that’s only for large teams over 5. And with MSDN you get these benefits included.
  • Lastly, if you attended and enjoyed the presentation – give a shout out to Donovan on Twitter. He’s thrown down the gauntlet – “we have the best build and release tools on the market, if you don’t agree reach out to me on Twitter and be specific!” So, if you don’t think Microsoft’s build tools will work with Jenkins, or Java apps, Node.js, SonarQube etc – throw down and enter the squared circle my man!

My notes are below. These aren’t notes of his presentation as they were no-slide demos, but comments Donovan made during the day that gives DevOps context to his presentation. As the saying goes, “If I had more time it would have been shorter!”

 

 

 

Thoughts on Strategy

Make incremental changes in ramping up your maturity. It’s safer. If you are deploying manually, there’s one part that you fear the most. Focus on that.

“If it hurts, do it more often.” (You are incurring more risk by deploying less frequently.) Lean forward into that and think about, how can I fix this. Focus on scariest part first.

If you need prescriptive – hire a consultant. (Like, I don’t know, Microsoft Premier for Developers maybe!) They can ask questions, pinpoint pain points for your org and provide a specific roadmap.

Why do you have to ask permission from your manager? Your job as an engineer is to continuously deliver value. You should need to ask permission if you DON’T want to set up CI. No need to stop and learn for months – focus on what hurts the most, and focus on that one thing. What is the thing – every time you run a deployment – why it breaks. Otherwise – you end up paying a tax doing it manually. Find something small to focus on – don’t try to do it all at once. It might take you months – after which you may have an amazing portion of your pipeline that was manual that is now automated. That will get people excited. And after that last build that blows up when people start playing the “Not it” game – guess what, you get to go home early!

And if you’re stuck on exactly where do we start? – http://donovanbrown.com/post/How-do-we-get-started-with-DevOps (really, check this post out. It’s good enough to mention twice!)

 

Agile Is Your Starting Place

The key question is – “Can you produce releasable bits of code?” Until your Agile processes are strong – not perfect but mature – you can’t see significant gains with DevOps. The business needs to understand that we need to produce increments of shippable code. DevOps is the “second decade of Agile.” Once Agile is in place you will realize that you’re not able to ship as fast as you can produce features.

What limits us so far – four years after “The Phoenix Project?” Really it’s still slowed by adoption of Agile. 40% of orgs have adopted Aguke. That’s a dead number, as its only dev teams that are championing this. The rest of the org is expecting waterfall, requirements, dates.

DBA’s are frequent blocking point. If you slice vertically and not horizontally. I’ll give you 3 months, if you promise not to make any further changes to the schema, ever. “That’s crazy!” “If you’re going to change it anyway why should I invest 3 months in this now. Your first step could start with login functionality – in 3 weeks we have a login page, username and credentials, authentication and identification.” Don’t let a recalcitrant DBA stop you in your tracks.

One week sprints really worked well (at one company) for Donovan in his consulting past- with product owner/business owner. After 8 weeks, needed to get a knowledgeable person (replacing old business owner) – and a sigh of relief, finally back on track. And hire a scrum master. That person needs to be able to say no to the boss. For a good product owner, all they have to do is understand the business they are trying to serve – and tell me of two backlog items which one is a priority. Scrum Masters must protect team from unrealistic expectations, on this date, I want these features – perfect quality. Quality is not negotiable – either move date or lose features.

 

Database Goodies

SQL Server Data Tools (SSDT) – version every object on SQL Server including permissions and roles. Stored in a database project. (this is free. Evaluate, see if it meets your need.) An amazing tool, been around for 10 years, very little known – our best kept secret! If SSDT for some reason isn’t scaling or working for you – ReadyRoll from RedGate is also a good option.

 

Last but not least – this amazing site brought to my attention from Jorge Segarra. An awesome resource for all things DevOps for you DBA guys! https://www.microsoft.com/en-us/sql-server/developer-get-started/sql-devops/

This may require breaking up into diff schemas (like a virtual namespace) vs one huge project. Schemas are here now and available; will allow you to segment databases that you create – no 3000 tables/etc in one untranslatable blob. (BACPAC is schema and data, DACPAC is just schema. Can run post/pre scripts- make sure its idempotent so if it runs twice you don’t double your db size!)

Migrating your CRUD statements from sprocs to Entity Framework may be a win to move away from thousands of unwieldy and clunky INS/UPD/Del type statements.

 

Integration Testing (Selenium etc)

DevOps – one company said “DevOps = Automation”. So they had thousands unit and integration tests. Code would flow with no human intervention from commit to production. As soon as they release a CSS change though to prod, they start losing money. As soon as they started looking at ecommerce website – summary page made final buttons and the text the same color- this resulted in a blank button! Automation clicked it because the ID of the button did not change. So, automate everything you CAN – don’t try to automate things you shouldn’t.

Best practices for building integration tests: the #1 thing is making sure assumptions you made when you recorded your automation are still valid. Usually the database in QA is the failing point: the code isn’t broken but the data it runs against doesn’t fit assumptions. See Redgate’s excellent tool SqlClone here.) They are a few versions behind with their Selenium driver, using IE.

“We spend more and more time with peer testing than we do with auto testing on the Microsoft VS team. As we’re our own first customer, there’s a lot of A/B testing that happens. Integration testing happens very little, unless there’s a performance issue – then we move it to GoBig environment where we can perf test.” Per Brian Harry – “Unapologetically we do testing in production.”

Donovan ran a team in Akron where they were not allowed to write a line of code until they wrote a UI test (in CodedUI, but now we do this in Selenium). They wrote automation before they wrote code – wrote so it fails, then refine until it passes. This and a manual test case – which can be given to a stakeholder in plain English (“oh, I didn’t expect I should be pressing that button”) – there’s nothing better than a manual test case to be your new acceptance criteria. Automation and UI tests are brittle – they become brittle/break, that didn’t go away, but having it there forced my teams to do the right thing early. (These were one week sprints, Weds to Weds.) Do it more often if it hurts! Finding clever ways of making BACPAC/data layer work.

VS teams – forced them to move more functionality to behind the scenes, UI testing. Make unit testing viable. To those nerd architects out there claiming that “Unit tests are worthless”! – we run 41000 unit tests in VSTS and it takes 6 minutes. You can’t run integration tests that fast.

 

Infrastructure as Code (ARM templates) and Configuration Management (PowerShell DSC)

ARM (Azure Resource Manager) is the name of the game here to get Infrastructure as Code working. This is a much better process than spinning up resources manually for example. (Not configuration here – doesn’t include IIS, etc. )

Recommendation: Introduce your Infra team to ARM templates. ARM templates are Azure only but you can use Terraform to point to Azure/multi-cloud solution so you can move resources to Google/AWS etc.

Configuration as Code – using PowerShell DSC (Desired State Configuration) – take configuration of that server and you codify it as well. (I demand you have port 80 open, .NET 4.5, IIS available, these security roles etc.) Server installs everything you need to bring it to ready state. Every 15 minutes – checks to make sure it fits standard config. So, if it finds that IIS is turned off, it will detect if the configuration is drifting and make a note in the log. You can also configure it to bring it back to standard state.

PowerShell DSC works for both Linux and Windows environments. And, it’s free! (p.s. Chef uses DSC as well so it’s a layer on top of a layer.)

Recommendation: Start with what you have and what’s free with PowerShell DSC and THEN make an evaluation if there’s features that are missing. This could take <1 hour. From Donovan – “I encourage you to ping me on Twitter if DSC is not getting the job done. If we can’t fix it fast enough, then go to Chef or a competitor.”

DSC can be done onprem/etc. It’s idempotent, which means you can run it blindly a million times in a row and the server will stay exactly the way it needs to.

 

 

Self Service VM’s with Dev/Test Labs

Struggling with self service VM’s and exposing costs of resources to the consumers you service? (I.E. that 5 9’s coming at a horrendous price that is shielded from end users/business?) Think about Dev/Test Lab. This is Self service – no blank check, you can spin up a sandbox (using allocated $ your customers buy each month) and enforces the VM images they are allowed to spin up.

Dev/Test Lab documentation – https://docs.microsoft.com/en-us/azure/devtest-lab/

Overview and trial site hub – https://azure.microsoft.com/en-us/services/devtest-lab/

Starting documentation, very good – https://docs.microsoft.com/en-us/azure/devtest-lab/devtest-lab-overview

 

Microservices

Of advantage because releases now are micro sizes. No more having to track down 6 months back with a dictionary of changes. Would eliminate webmethods – ESB. Can rev very quickly on microservices without jeopardizing the application as its very small, atomic pieces of functionality.

Meant to be combined with containers.

Not a silver bullet. Evaluate it. Microsoft is going there on VSTS team. Docker support is built into VSTS – can publish to a registry. Even TFS 2015 update 3-4 has Docker support as well. Need to also run Win Server 2016 to support containers, or Linux containers. Anniversary edition of Windows 10.

 

Starting and Scaling DevOps in the Enterprise – review

As many of you know, I’m a huge fan of the work Gary Gruver has done – in particular his book “Leading the Transformation” on his experiences at HP trying to transform a very traditional enterprise. (See my earlier mention of his book on this blog, here.) His newest work is out – Starting and Scaling DevOps in the Enterprise. I am recommending it very highly to all my customers that are following DevOps! I think its unique – by far the best I’ve read so far when it comes to putting together specific metrics and the questions you’ll need to know in setting your priorities.

Gary notes that there are three types of work in an enterprise:

  1. New work – Creating new features or integrating/building new applications
    1. new work can’t be optimized (too much in flux)
    2. Best you can hope for here is to improve the feedback loop so you’re not wasting time polishing features that are not needed (50%+ in most orgs!)
  2. Triage – finding the source of defects and resolving
    1. Here DevOps can help by improving level of automation. Smaller batch sizes means fewer changes to sort through when bugs crop up.
  3. Repetitive – provisioning environments, building, testing, configuring the database or firewall, etc.
    1. More frequent runs, smaller batches, feedback loop improved. All the DevOps magic really happens in #2 and #3 above as these are the most repetitive tasks.

Notice of the three types above – the issues could be in one of five places:

  1. Development
    1. Common pain point here is Waterfall planning – i.e. requirements inventory and a bloated, aging inventory)
  2. Building Test Environments
    1. Procurement hassles across server, storage, networking, firewall. Lengthy handoffs between each of these teams and differing priorities.
    2. Horror story – 250 days for one company to attempt to host a “Hello World” app. It took them just 2 hours on AWS!
  3. Testing and Fixing Defects – typically QA led
    1. Issues here with repeatability of results (i.e. false positives caused by the test harness, environment, or deployment process)
    2. Often the greatest pain point, due to reliance on manual tests causing lengthy multi-week test cycles, and the time it takes to fix the defects discovered.
  4. Production Deployment – large, cross org effort led by Ops
  5. Monitoring and Operations

The points above are why you can’t just copy the rituals from one org to another. For any given company, your pain points could be different.

 

So, how do we identify the exact issue with YOUR specific company?

  1. Development (i.e. Requirements)
    1. Metrics:
      1. What % of time is spent in planning and documenting requirements?
      2. How many man-hours of development work are currently in the inventory for all applications?
      3. What % of delivered features are being used by customers and fit the expected results?
    2. An important note here – organizations often commit 100% of dev resources to address work each sprint. This is terrible as a practice and means that the development teams are too busy meeting preset commitments to respond to changes in the marketplace or discoveries during development. The need here is for education – to tell the business to be reasonable in what they expect, and how to shape requirements so they are actual minimum functionality needed to support their business decisions. (Avoid requirements bloat due to overzealous business analysts/PM’s for example!)

  1. Provisioning environments
    1. Metrics:
      1. How much time does it take to provision environments (on avg)
      2. How many environments are requested per month/sprint
      3. % of time these environments require manual fixing before they are complete
      4. % of defects associated with non-code – i.e. environments, deployments, data layer, etc.
    2. The solution here for provisioning pinch points is infrastructure as code. Here there is no shortcut other than developers and IT/operations working together to build a working set of scripts to recreate environments and maintaining them jointly. This helps with triage as changes to environments now show up clearly in source control, and prevents DEV-QA-STG-PROD anomalies as it limits variances between environments.
    3. It’s critical here for Dev and Ops to use the same tool to identify and fix issues. Otherwise strong us vs them backlash and friction.
    4. This requires the organization to have a strong investment in tooling and think about their approach – esp with simulators/emulators for companies doing embedded development.

  1. Testing
    1. Metrics
      1. What is the time it takes to run a full set of tests?
      2. How repeatable are these? (i.e. what’s the % of false errors)
      3. What % of defects are found with testing (either manual, automated, or unit testing)
      4. What is the time it takes to approve a release?
      5. What’s the frequency of releases?
    2. In many organizations this is the most frequent bottleneck – the absurd amount of time it takes to complete a round of tests with a reasonable expectation the release will work as designed. These tests must run in hours, not days.
    3. You must choose a well-designed automation framework.
    4. Development is going to have to change their practices so the code they write is testable. And they’ll need to commit to making build stability a top priority – bugs are equal in priority (if not higher than) tasks/new features.
    5. This is the logical place to start for most organizations. Don’t just write a bunch of automated tests – instead just a few automated Build Acceptance Tests that will provide a base level of stability. Watch these carefully.
      1. If the tests reveal mostly issues with the testing harness, tweak the framework.
      2. If the tests are finding mostly infrastructure anomalies, you’ll need to create a set of post-deployment tests to check on the environments BEFORE you run your gated coding acceptance test. (i.e. fix the issues you have with provisioning, above).
      3. If you’re finding coding issues or anomalies – congrats, you’re in the sweet spot now!
    6. Horror story here – one company boasted of thousands of automated tests. However, these were found to not be stable, maintainable, and had to be junked.
    7. Improve and augment over time these BATs so your trunk quality gradually moves closer to release in terms of near-produciton quality.
      1. Issue – what about that “hot” project needed by the business (which generally arrives with a very low level of quality due to high pressure?
        1. Here the code absolutely should be folded into the release, but not exposed to the customer until it fits the new definition of done: “All the stories are signed off, automated testing in place and passing, and no known open defects.”

  1. Release to Production
    1. If a test cycle takes 6 weeks to run, and management approval takes one day – improving this part just isn’t worth it. But if you’re trying to do multiple test cycles a week and this is the bottleneck, absolutely address this with managers that are lagging in their approval or otherwise not trusting the gated testing you’re doing.
    2. Metrics
      1. Time and effort to release to production
      2. Number of issues found categorized by source (code, environment, deployment process, data, etc)
      3. Number of issues total found in production
      4. MTTR – mean time to restore service
      5. # of green builds a day
      6. Time to recover from a red build
      7. % of features requiring rework before acceptance
      8. Amt of effort to integrate code from the developers into a buildable release
    3. For #1-4 – Two areas that can help here are feature toggling (which you’ll be using anyway), and canary releases where key pieces of new functionality are turned on for a subset of users to “test in production.”
    4. For #5-6 – here Continuous Integration is the healer. This is where you avoid branching by versioning your services (and even the database – see Refactoring Databases book by Scott)
    5. For #7-8 – If you’re facing a lot of static here likely a scrum/agile coach will help significantly.

 

So – how to win, once you’ve identified the pain points? You begin by partitioning the issue:

  • Break off pieces that are tightly coupled versus not developed/tested/deployed as a unit. (i.e. HR or Purchasing processes)
  • Segment these into business critical and non-business critical.
  • Split these into tightly coupled monoliths with common code sharing requirements vs microservices (small, independent teams a la Amazon). The reality is – in most enterprises there’s very valid reasons why these applications were built the way they are, You can’t ignore this complexity, much as we’d like to say “microservices everywhere!”

I really admire Gary’s very pragmatic approach as it doesn’t try to accomplish large, difficult things all at once but it focuses on winnable wars at a company’s true pain points. Instead of trying to force large, tightly coupled organizations to work likely loosely coupled orgs – you need to understand the complex systems and determine together how to release code more frequently without sacrificing quality. Convince these teams of DevOps principles.

DevOps – Where to Start

I had a friend come to me the other day with what seems to be a simple ask. His company, a large banking enterprise, is looking into DevOps. So where should he start in building awareness?

Some context here – my friend is a programmer, a lifelong developer with high-level black belt skills in a variety of languages. He doesn’t want this to become a full time job for him – he loves coding and application development/architecture in particular. He just wants some resources to pass along.

Here’s my response:

A few words first on what DevOps is…

If you’re just getting started, there’s a decent Microsoft site out here at this address. Including a great series of videos that introduce what DevOps is and means, with some really rich content in the footnotes for next steps..

DevOps means in practical terms making sure your release pipeline from a development workstation to production is as smooth and automated as possible. So that implies:

  1. Infrastructure as Code: You have your infrastructure written out as a recipe and it’s rebuilt each time you push out code (Infrastructure as Code). Following a template enforces consistency, it’s the only sane way to handle things. The big players in this space to date are Chef and Puppet, maybe Octopus.
  2. Testing: Your testing is as rigorous as possible. This means when you do a release no person needs to look at anything but exceptions where there’s failures – your releases are gated where if there’s major bugs you’ll catch them early on and prevent a release to production. This means integration and unit testing using things like Selenium for the UI layer.
  3. Release Management: When developers check in code its continuously integrated and released. Note – this is mostly IDE based. I believe MSFT has best in class tooling here especially built on top of VSTS releases, where essentially it becomes fire and forget, a checkbox. (Remember when Agile used to be hard?)

For my open source friends – the big players in the industry right now come from the Linux community. So start in your learning efforts with Chef (https://learn.chef.io/) and Puppet (https://puppet.com/download-learning-vm) . Ansible is also a hot name. You can download VM’s and start playing with them, or run these tools on the cloud, free with Azure, and they’re Linux based, very easy on the $.

OK, That’s Great. Now What?

Well, if you want to tackle this, and you’re book oriented, I would recommend the following:

The “Gang of Four” Books:

  1. Get “The Phoenix Project” by Gene Kim. This is great in particular for you executive/leadership types. Think about leaving this on the desk of decisonmakers you know if you need support for your DevOps initiative.
  2. Another, very practical book is “Leading the Transformation” by Gary Gruver and Tommy Mouser. This is a much more connected approach on how one leader found a way around serious organizational constraints – yes your efforts will make enemies if handled badly! – by chaining it to specific business (not technical) phased objectives. A must read.
  3. You developers out there should already have “Continuous Development” by Jez Humble on your bookshelves. It’s a modern classic and explains why developers should be 100% onboard with RM and continuous delivery movements.
  4. IT people need to pick up a copy of “Visible Ops” by Gene Kim, very prescriptive and outstanding in basing your transformation on key IT/operations based KPI’s. Nonfuzzy, clear, short and sweet at about 100 pages in a little booklet. I love it.

Yeah, I’m more into videos. Books are so 90’s, dude.

OK, well do you have 12 minutes? Check out this intro with Donovan Brown,  and an excellent three part series on Release Management – Part 1 (overview), Part 2 (RM architecture), and Part 3 (release pipelines). Outstanding, and will give you a nice overview of setting up Continuous Integration and build pipelines.

My blog has some links on “All Happy Families Are Alike“, “Devopoly“, “Cats and Dogs Living Together“, and “The Five Dysfunctions of DevOps“. These are lengthy but put together will give anyone a good overview of the Phoenix Project and Visible Ops.

Now We’re Getting Started…

Well that’s enough to at least whet the appetite.

Here’s the three things I’d like you to come away with:

  1. DevOps is a big effort, you will need help. You can’t do it grass roots. It will require strong commitment by management and the understanding that this will require both time and money. If you feel that you lack that level of commitment, manage expectations or scrub the effort until the conditions are more favorable. Likely, you will need some experienced help to form a roadmap and get buy-in, and coach/mentor so the first few months go smoothly. You will also need to commit time and effort to mastering and maintaining your code for both testing and building out your infrastructure. (Hopefully, your releases themselves will be mostly code-free).
  2. Build maturity through better testing. Your gated releases are going to need a high level of assurance that your builds are functional. So building up your QA maturity is one big investment that will pay huge dividends in avoiding production mishaps and environmental anomalies that come through manual deployment methods.
  3. Infrastructure As Code is where its at. As long as environments are manually provisioned, you have a vector for errors and time-sucking anomalies. Once you start writing out environments as recipes and going away from manual patching to destroying/rebuilding environments along with your production releases – you’ll never, ever go back. It rocks!

Thanks guys, hope this is helpful to you with those first few steps on your journey!