AsPlanned.app

Starting the Journey

• The first one is that the 'Environments' in Contentful are a great thing for building and testing stuff, but it is (or at least it was) claimed that 'Environments' are just like Git 'Branches'. And that is actually not true. I get it, it's to make a user relate and understand those Environments better, but in reality you can't manage them really like Git Branches, not even close. But it's sort of possible (with some work).
• The second thing that bugged me was kind of what makes me like Contentful. They give you a broad set of tools, SDKs, APIs, tutorials and so on, but the last '20%' is left to you, the developer, to personalize and figure it out. It's a fair trade, since being too specific would inevitably make it less useful for different contexts and would bring an additional layer of technicality. In addition, it would be difficult for them to shape and change their APIs over time to accommodate more specific use-cases. But nonetheless, although building that last-mile is exciting as a Developer, I can't shake the feeling that things could be better.

Building is the key

• An 'environment' exporter, built on top of Contentful own exporter library, to do something very simple: export a Contentful Environment into a ZIP file, when running the script in the CI/CD. The script would know the right Contentful Environment, and export both the JSON with all the entries and a folder with all the images/assets. It would then ZIP everything and make it available as a CI/CD Artifact.
• A 'migration' system that is Environment dependent, and doesn't need a centralized server to know which migration has run and which one has not. Similarly, the second step was to save the migration 'number' inside Contentful itself (you just need a key-store Content-type), like many databases do, and then just save JavaScript Content-type migrations inside a folder, using an incremental number. That was easy enough to implement, but what I didn't foresee was how useful it was to be able to have migrations applied in the CI/CD during deployment. It was a step further into really starting to treat the Contentful Environments as Git Branches.
• The third script was a 'release management' tool. Meanwhile the first 2 scripts were kind of utilities that anybody could write, the third script was a more flashed out CLI script to help really (or I would say, finally) treat those Environments like Branches. Duplicate, verify them, sync their schedule (that is usually not duplicated between Environments), create aliases and whatnot. This script has been really what made it possible for us, at Atida, to work with Contentful in a way that was neither disruptive or invasive for content editors.

• They were not meant to be re-used. As any professional developer reading, you can surely relate. In my mind everything was perfect, but in reality the code had some trade-offs: hard-coded paths, constants that we only would use; it had methods that were not consistent and it wasn't following any particular 'standard' in the way some things looked (a method could have more logging, or the order of the parameters different from one another). And this is kind of natural. The first scripts and functions didn't have the quality of the latter ones. But when you work, you have to deliver, so you can't just try to perfect the code again and again.
• The second problem was realizing that 'people will look at my code'. It seems silly to say, but coming from a PHP background I started reflecting on the fact that I'm not probably the most experienced Node.js developer, and so it kind of made me think twice before showing the code we made. Surely I didn't want people to think I didn't put the effort into making the code look good or be readable enough.
• The third problem was that I never released an NPM package. So that was also a thing: it's easier to do something you know. So trying to think what to release, but being in the darkness about how to do it, surely didn't help with the general feeling of 'wanting to do some Open-Source'.

What did I learn?

• Coding is fun - Having done professional Software Development for 15 years, I do love to code, but I would lie if I would say that every moment of every day at work is fun. It's not! Don't get me wrong. I feel blessed that I get to do a job that I like, but not all the job is equally fun, and not all the job is just coding. You have dailys, meetings, road-maps, refinements, and whatnot to 'distract' you from coding (some of these meetings help you, but still). And even when you have to actually do the job, sometimes you have no clue, you have to figure out what to do and you don't know the best way, cause you haven't done it yet. There is a 'procrastination' / 'digestion' process that makes you not really coding, just processing all the information. So some parts of the job are not fun, they are not meant to be. On the other end, when coding for yourself, on your own terms, it is a lot of fun. It's like when you were trying things out before you ever became a professional. It's refreshing and it sparks a lot of creativity.
• But it's really hard - But it's still really hard. The reason(s) are that nobody really tells you what to do, but it also means that it is really easy to go down the pitfall of 'never finishing' something. Maybe you want to make it perfect, or just add a new method. So the hardest part is probably to remind yourself that even if it's free and it's fun, you can't just do that forever. You should treat it like a job. At one point, you need to decide that the code is ready, stop over-engineering and just release it. Also rewriting things like 10 times just to make them better, starts to wear you down and makes you lose clarity. Maybe that's how a 'scrum-style' sprint should look like. You deliver, you take your eyes off of it for a couple of days, and then you work on the next version. You'll probably see things more clearly.
• Help from ChatGPT - I'm a Software Developer, but I use ChatGPT to help me code or figure out things. And I have no shame to say that is probably one of the best things as a developer that I could do. I started using ChatGPT to help me optimize and improve the code I was going to release, and it showed me some nice tricks or ways of doing things that I wasn't aware of before. So, for the people that are scared AI will take your job, it won't, but you should be using it for your own personal growth to make you become a better developer. And once you learn a new way of doing things, or just how to write a better JSDoc, you can then use that in all the rest of the code. That's what I did for my Contentful Lib Helpers.
• Still TO-DO - But as I said at the beginning, at one point you have to release. And I feel it's better to release something useful and still have things TO-DO, than wait till everything is done. I know, I should add more tests, and probably a better way of handling the messaging, or just some optimization and improvements that will make the whole library better, but for now, this is a good trade-off. Maybe at one point I will rewrite everything using Typescript - we'll see.

Special Thanks to...

• Contentful - Well, Contentful just for creating the platform and all the amazing ecosystem.
• Atida - My former company. An health/beauty products E-commerce, that supported this initiative.
• Shaya Pourmirza - My former manager, amazing person and great professional.
• Aldo Fernández - Probably one of the best FE developers I ever worked with. He thought me a lot and these scripts are heavily his contribution as well.