It's taken me exactly two weeks to recognise the value of a native editor like Sublime Text 3 used for Ansible automation and Python scripting. I'm so impressed with the benefits brought by this approach that after another gentle reminder to perhpaps make the purchase already, I decided to hit the button.
WARNING: this is going to be a summary of my approach and view of local text editing on MacBook. HOWEVER, I just swiped something incorrectly and WordPress lost the whole post I've been typing up for about an hour. So I'll have to revisit and fill in the blanks later.
My Background with Text Editors
Why Not Just Use Editor in Remote Session?
Can't I use gVim or neoVim Instead?
Great Reasons to Use Native Editor
I'm listing things I enjoy specifically in Sublime Text 3 editing Ansible playbooks on my Macbook, but many modern editors bring similar improvements (unfairly) compared to out-of-the-box vim session on a typical Linux instance.
Functional Benefits of Editing Locally
- better view of file navigation – Sublime Text 3 has folder view on macOS and even highlights git status for all the files
- easier editing of multiple files with tabs – I like most apps with tabs in their interface, Sublime Text 3 definitely feels right with their approach. Tabs are easy to create and navigate, files are quick enough to be found using fuzzy search in filenames.
- great syntax highlighting, navigation and indentation – Sublime Text 3 shows the big preview of your whole text time in the right section of the window, gives you line numbers and shows how many spaces/tabs you have in each line – makes it much easier to tabulate
- bigger, more flexible access to source code and repos – your workstation can contain multiple projects and configuration files for various servers – you won't get this on individual servers and probably won't get it even on a dedicated automation server like Ansible/Puppet server – because they're usually dedicated to a client/project
- Quicker search in file and filesystem – I'm only learning how to use this properly in ST3, but there are plenty of ways to find something in a whole tree of directories pretty quickly
- Convenient access to plugins – this is definitely one of my favourites. In many companies you just don't get the same flexibility with installing software or plugins on any servers. You're at best discouraged from installing non-signed/downloaded from Internet (not originating from a signed software repo) softare. And you're completely blocked access at worst – firewall rules or AWS security groups need to be updated if you were to download anything directly on the server. Uploading plugin via scp is always an option, but many add-ons have dependencies which are a pain to resolve without readily availalbe Internet connection.
Quality Improvements in DevOps tasks
- less risk to break syntax in some config – you're comfortably editing, there are plugins checking and highlighting syntax, there may be commit hooks and peer reviews in your process to minimize risk
- automatically more global and generic thinking – because you're probably working on automation (Ansible) rather than actual config files, your mindset and your approach to solving an issue becomes more global. I notice that even when creating a playbook for just one server or VM, I'm already building it with scalability in mind – no hardcoded hostnames or functions, all the necessary flags and host specific variables. If time allows, I'm even implementing the same software install/configuration for both Debian and RedHat familiy of systems – just in case.
- better source code control – most of things I write locally will be automation or documentation, meaning they almost definitely end up on github. There's better history, better change trackign and more flexible way of rolling things back – all the usual improvements of using git
- definitely less temptation to mess around with any server directly – I have all the information, all the configs and templates here locally in my git repo. Logging in remotely to some server for fixing a problem becomes an extra step if not a hassle – and I like it this way, because this means my solution will be this bit more robust by the time I get to deploy