Following the "Start Developing Your First Helix Project in 60 Seconds" guide gives a good start point with Helix. This is what I would call "step 1" and being approved with adobe/helix-cli#711.
Step 2 would be the first publishing of the site which requires some insights from the Helix team (like how to setup Fastly / I/O Runtime). It does not make it easy, but this is still fine for now so that we can control who is using Helix and we lack of certain automation tool (like create a Fastly service, I/O Runtime account...)
The step 3 is everything that comes right after the first publishing like testing a new version of my site, deploying / publishing again and again and iterate on the code (branches) or on its content...
Things start really to get complicated and non-intuitive event for someone like me who has done the exercise multiple times right from the beginning of step 3.
Once my first version of the site is live, the first thing a dev does is to create a v2
branch. This has been validated during the hackathon, you do want to make the changes directly in master
.
Issue number 1: running hlx up
in a local checkout with a different branch does not render my local code but the one from GitHub master
branch because it is setup like this in the helix-config.yaml
.
Possible solution: get rid of the code
property in the strains by default. You may add one if you know what you are doing.
To solve that problem, I do not really know what is the good solution:
- temporarily hack the default strain to refer to my branch (and use
--local-url=.
- might be the default now)
- add a new strain with code / static references to my branch (and use
--local-url=.
- might be the default now) but then I need to use the url
property to make sure that locally it gets to my new strain and not to the default one.
This is way too complicated.
Issue number 2: In my temporary code v2
branch, my helix-config.yaml
starts to diverge and when v2
will be merged, I do not want a reference of v2
in my helix-config.yaml
.
Possible solution: do not use strain at that stage, there should a better way.
Now I want to test my branch live. Knowing that there are fondamental differences between the simulator and Fastly, as an advanced developer I must test my code in a production like environment.
In my local checkout of my branch, I need to swap my .env
file to get the "test env" and not the "prod one"
Issue number 3: There is a huge risk here that I forget and I overwrite the prod
Possible solution: hlx deploy
and hlx publish
should ask me to confirm the namespace / services I am going to update.
Then I need to deploy the code, which in the end I do not really care about. As a developer here, I want to "publish" my site, whatever needs to happen should happen.
Issue number 4: hlx deploy
and hlx publish
belong together for a simple user. They should be one operation.
Possible solution: create a single cmd that executes both.
Issue number 5: hlx deploy
will complain and force you to add a strain for the v2
branch which I can add automatically with hlx deploy --add v2
. The pb is that I have no clue what add
will do, it is a separate operation that I want to do before to check the result.
Possible solution: extract the --add
option into either a standalone cmd or at least it a single operation of the deploy
I am not going to use the prodution Fastly service, too risky. I have my own Fastly service "acapt - Playground" where I want to publish to. Again here, the risk that I publish to the wrong service is really high (I managed to break 3 services in 2 days because of wrong service id).
Now I can go to my test domain and validate that everything works as expected.
I can merge my code change (+/- the extra unnecessary strain) and do the same operations from my updated master
branch.
One might say that this is ok because it will be run by a CI anyway. That's what I try to do too. Actually, you can replace the "I" by "CI" in all the sentences above and you end up with the same result. I did not manage to automate the CI for a dev branch (only deploy / publish on commit to master).
The main issue I see here is the number of conflicting dimensions: branch vs strain vs domain. The fact that hlx deploy
needs a strain for the current branch and finally updates the helix-config.yaml
with the package reference illustrates there is a duplicate on the code side (url + package reference).
One proposal would be to remove the code and static url from the strains and just keep the content url, the staticRoot and the url / condition (+extra configs).
When you run hlx superpublish
, you do it from a code checkout anyway, thus you know the code url, static url and the branch, it can then deploy and publish with everything you need. If hlx superpublish
asks you which service id (showing the nice names we have in Fastly), you are sure of where it goes (with shortcut flags for the CI).
After hlx superpublish
, you simply need to commit the patched helix-config.yaml
to keep history of the deployment.