Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inv staging deploy #15

Open
vkurup opened this issue Jul 15, 2020 · 6 comments
Open

inv staging deploy #15

vkurup opened this issue Jul 15, 2020 · 6 comments

Comments

@vkurup
Copy link
Contributor

vkurup commented Jul 15, 2020

It would be nice to get inv staging deploy to be the only command that a dev needs to memorize to do a deploy (similar to how we used to just do fab staging deploy.

Currently inv staging deploy does this:

$ inv staging deploy
cd deploy/ && ansible-galaxy install -f -r 'requirements.yaml' -p roles/
- changing role caktus.django-k8s from v0.0.5 to v0.0.5
- extracting caktus.django-k8s to /home/vkurup/dev/caktus-website/deploy/roles/caktus.django-k8s
- caktus.django-k8s (v0.0.5) was installed successfully
Traceback (most recent call last):
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/config.py", line 111, in __getattr__
    return self._get(key)
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/config.py", line 176, in _get
    value = self._config[key]
KeyError: 'tag'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/bin/inv", line 8, in <module>
    sys.exit(program.run())
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/program.py", line 384, in run
    self.execute()
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/program.py", line 566, in execute
    executor.execute(*self.tasks)
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/executor.py", line 129, in execute
    result = call.task(*args, **call.kwargs)
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/tasks.py", line 127, in __call__
    result = self.body(*args, **kwargs)
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/kubesae/ansible/deploy.py", line 30, in ansible_deploy
    tag = c.config.tag
  File "/home/vkurup/.pyenv/versions/3.7.6/envs/caktus-website/lib/python3.7/site-packages/invoke/config.py", line 123, in __getattr__
    raise AttributeError(err)
AttributeError: No attribute or config key found for 'tag'

Theoretically at least, we could catch that error in ansible/deploy.py line 30, and run the image task. Thoughts?

@dchukhin
Copy link
Contributor

It would be nice to have something better than an AttributeError for this case.
It seems to me that implicitly running the image task may cause undesired behavior, though, for example if someone is trying to deploy to production and doesn't want to build a new image to deploy. Maybe something like catching the error and telling the user to supply a tag/build a new image is better? We could even try to give a command to get the most recent tags , like this for GCP repos:

print(
    "\nPlease specify a tag to use for the deploy. You can see the 10 most "
    "recent images and their tags with:\n    "
    f"gcloud container images list-tags {c.config.repository} --limit=10"
)

@vkurup
Copy link
Contributor Author

vkurup commented Jul 16, 2020

Hmm, I disagree with the second part of that. We've always done fab production deploy without forcing the user to specify which version of the code they want deployed. The most common thing to do should be the easiest thing to do. If, in your example, they really did make the mistake of wanting to deploy a specific tag, they would see that a docker build command was kicked off and would have plenty of time to Ctrl-C out if it. My hope here was to make things simpler for the user, rather than more complicated.

@vkurup
Copy link
Contributor Author

vkurup commented Jul 16, 2020

But I also like that command that you showed as an advanced option, in the case that you wanted to rollback a deployment quickly to a recently used tag. Maybe as a inv staging deploy:rollback? And if you didn't provide a tag to the rollback command, it would list recent tags for you to choose from? (My 2 cents, of course)

@dchukhin
Copy link
Contributor

The rollback option sounds like it could be useful, and I agree that making things easier for the user is desirable. I do think we should put in something that would prevent people from accidentally deploying the wrong code, though (whether on the command line or in the config, etc.). I want to avoid the situation where being on the wrong git branch during a deploy or having uncommitted changes during a deploy means the wrong things get deployed.

@vkurup
Copy link
Contributor Author

vkurup commented Jul 16, 2020

Ahh, that is an excellent point! Then my suggestion would be:

  1. If the user is on the correct branch for the environment (which we'd have to specify somewhere) and if the tree was not dirty (which we already have some code in place to check), then fab <env> deploy would run image automatically. This would make things simple for the most common scenario.
  2. If either of those things is not in place (wrong branch, or dirty tree), then we abort with a more useful error message.

@dchukhin
Copy link
Contributor

That sounds good to me.
🤝

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants