4 ms·

Hm, it’s different for me. Since at work I don’t really do the Continuous Integration/Delivery stuff (or anything with “real infrastructure”), I find it very en

by fuzzy2 5y ago

Hm, it’s different for me. Since at work I don’t really do the Continuous Integration/Delivery stuff (or anything with “real infrastructure”), I find it very enjoyable to fiddle with it at home. There’s no pressure to accomplish anything and I can just leave it alone for months or even years before coming back to it. There’s a nice side-effect, too: The CI definition documents how to compile the project. I recently dug out an old LaTeX “project” and there was nothing, no Makefile or anything. Had to look up everything again to get it to run (with XeLaTeX and Biber).

spion 5y ago
It also really depends on what you find cool, there are different ways to look at things. For example if I think of pipelines as these execution graphs that run on their own and make sure your artifacts end up in the right place, then its really fun. CI systems that visualize this make it even more interesting. A little combination of the right personal interests and perspective goes a long way towards building up resilience to deal with the ugly bits.
- Netcob 5y ago
  I had this interesting experience back in university. We were doing some simple web service project in pairs, and it consisted of a program and some devops stuff. My partner in that project turned out to have skills that exactly complemented my own - he had trouble with the algorithmic stuff that I thought was trivial, yet he easily stitched all the services together by editing some configuration files before I even understood what any of them were for.
NBJack 5y ago
I would caution against trusting your build process definition to hold up to time. It's definitely better than nothing. Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).
- fuzzy2 5y ago
  It may not run to completion in the future, that’s true. However, if it’s something as simple as a shell script or a shell command list, it’s at least relatively transparent. Unlike, say, tasks on Azure DevOps. Not a fan of those.
majewsky 5y ago
> There’s a nice side-effect, too: The CI definition documents how to compile the project. Okay, sure, but that's not an argument for CI. That's an argument for a Makefile. In fact, I find myself going back to Makefiles all the time not in spite of all these specialized build tools, but because of them. Even if the steps are straight-forward for someone who's familiar with the tools, just having a Makefile there in the repository root will be helpful documentation to help someone new (or myself in 2 years) get started with how to build the stuff. For example, for LaTeX, it could be something like: build: slides.pdf handout.pdf %.pdf: %.tex pdflatex $* pdflatex $*

by fuzzy2 5y ago

spion 5y ago

It also really depends on what you find cool, there are different ways to look at things. For example if I think of pipelines as these execution graphs that run on their own and make sure your artifacts end up in the right place, then its really fun. CI systems that visualize this make it even more interesting. A little combination of the right personal interests and perspective goes a long way towards building up resilience to deal with the ugly bits.

Netcob 5y ago
I had this interesting experience back in university. We were doing some simple web service project in pairs, and it consisted of a program and some devops stuff. My partner in that project turned out to have skills that exactly complemented my own - he had trouble with the algorithmic stuff that I thought was trivial, yet he easily stitched all the services together by editing some configuration files before I even understood what any of them were for.

NBJack 5y ago

I would caution against trusting your build process definition to hold up to time. It's definitely better than nothing. Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).

fuzzy2 5y ago
It may not run to completion in the future, that’s true. However, if it’s something as simple as a shell script or a shell command list, it’s at least relatively transparent. Unlike, say, tasks on Azure DevOps. Not a fan of those.

majewsky 5y ago

> There’s a nice side-effect, too: The CI definition documents how to compile the project. Okay, sure, but that's not an argument for CI. That's an argument for a Makefile. In fact, I find myself going back to Makefiles all the time not in spite of all these specialized build tools, but because of them. Even if the steps are straight-forward for someone who's familiar with the tools, just having a Makefile there in the repository root will be helpful documentation to help someone new (or myself in 2 years) get started with how to build the stuff. For example, for LaTeX, it could be something like: build: slides.pdf handout.pdf %.pdf: %.tex pdflatex $* pdflatex $*