DevOps-ifying code changes

Hi all,

I was wondering if anyone here has gone beyond SFTP to deploy code changes using DevOps best practices, i.e. GitHub → CI/CD.

We use this workflow for other products that my team supports, but don’t have anything in place (yet) for our Livewhale implementation.

Thanks in advance,

Scott

1 Like

Not exactly but we do use code repositories. No updates are automatic, however. - we always push finished code manually.

We don’t use github but we do have local shared git repos. We use Nova for development, with separate sites (working directories) for our development and prod CMS, but both working directory repos are connected to the same origin repo for the website.

The dev branch in our repo is for finished, tested code that is ready to deploy. We branch that to work on specific dev projects and merge back into dev when those are tested and ready. The dev branch and project branches all publish to our dev CMS server and that is where we test. Sometimes, when only a quick patch is needed, we do the work right in the dev branch, but you know the dangers of that when the patch becomes more involved than expected.

When updates are ready in the dev branch it is merged into the master branch in the development working directory, and that is pushed to the origin repo.

Our prod working directory repo only checks out the master repo and when changes are ready the updates are pulled from origin and published to the server using sftp. No updates are automatic and this gives us a little more control over when and how things happen.

We currently have two developers and we manage to say out of each others’ way pretty well with this system.

I’m afraid the lack of automation may mean that this is not what you’re talking about, and sorry for long post…

Thanks Gian. Apologies for just seeing this now (busy week).

This is very helpful as our main goal is to move away from downloading / archiving code changes. Are there any Livewhale specific directories you leave out of version control (i.e. stuff that gets overwritten during each system upgrade)?

Thanks,
Scott

Yes - we’re selective about what goes into version control. Right now it includes everything in:
/livewhale/client
/public_html/_ingredients
/public_html/search

and a bunch of other stuff in /public_html that is specific to things we have built for our site. In general, we are careful not to include any LW core code, or things like regular pages that are managed through the CMS. Basically, anything we need to upload to or edit directly on the server goes in the repo, except for the config files in /livewhale/core. We’ve been pulling in more bits and pieces from /public_html as we work on them if they are things that are not edited in the CMS.

Actually, a lot of the things we build have components on our servers too, so we use separate repos for those projects, such as our newsletter systems which have some pieces in LW and some on our servers. That keeps the project together in once place which helps us keep things straight. We still leave anything that is edited in the CMS out of the repos for those projects too, though.

One other thing to keep in mind is that if LW updates any files that are in your repo as they do support work, you need to know which files they are and pull the latest down from the server into your repo so you don’t lose what LW fixed!

It’s not perfect, but so far, it has all worked out pretty well.

Hope this helps some…

Thanks, Gian. This is very helpful! I’m planning on setting up a GitHub repository in our organization within the next few weeks as we have some work in the pipeline.