Update docs

docs/developer/general/how-to/deploy-a-release.rst

@@ -3,68 +3,41 @@ Deploy a New Release
 
 **Remember to discuss any new deployments with the appropriate beamline scientist.**
 
-
-General deployment
---------------------
-
-The ``utility_scripts/deploy/deploy_mxbluesky.py`` script will deploy the latest mx-bluesky version to a specified beamline. Deployments live in ``/dls_sw/ixx/software/bluesky/mx-bluesky_vX.X.X``. To do a new deployment you should run the deploy script from your mx-bluesky dev environment with e.g.
-
-.. code:: console
-
-    python ./utility_scripts/deploy/deploy_mxbluesky.py --beamline i24
-
-
-If you want to test the script you can run:
+The ``utility_scripts/deploy/deploy_mx_bluesky.py`` script will deploy the latest mx-bluesky version to a specified beamline. Deployments live in ``/dls_sw/ixx/software/bluesky/mx-bluesky_vX.X.X``. To do a new deployment you should run the deploy script from your mx-bluesky dev environment with e.g.
+If you have just created a new release, you may need to run git fetch --tags to get the newest release.
 
 .. code:: console
 
-    python ./deploy/deploy_mxbluesky.py --dev-path /your-path/
-
-and a released version will be put in ``/your-path/mxbluesky_release_test``.
+    python ./utility_scripts/deploy/deploy_mx_bluesky.py i24
 
-If you need a specific beamline test deployment you can also run:
 
+If you want to test the script for a specific beamline you can run:
 
 .. code:: console
 
-    python ./deploy/deploy_mxbluesky.py --beamline i24 --dev-path /your-path/
-
-which will create the beamline deployment (eg. I24) in the specified test directory ``/your-path/mxbluesky_release_test``.
-
+    python ./deploy/deploy_mx_bluesky.py i03 --dev
 
-**Note:** When deploying on I24, the edm screens for serial crystallography will be deployed automatically along with the mx-bluesky release. 
-When running a ``dev`` deployment instead, `this script <https://github.com/DiamondLightSource/mx-bluesky/wiki/Serial-Crystallography-on-I24#deploying-a-local-version-of-the-edm-screens>`_ will also need to be run to get the latest version of the screens.
 
+which will create the beamline deployment of the new release in ``/scratch/30day_tmp/mxbluesky_release_test``.
 
-Hyperion deployment
--------------------
 
-The ``utility_scripts/deploy/deploy_hyperion.py`` script will deploy the latest mx-bluesky/Hyperion version to a specified beamline. Deployments live in ``/dls_sw/ixx/software/bluesky/mx-bluesky_vX.X.X``.
-
-If you have just created a release as above, you may need to run git fetch --tags to get the newest release.
-
-To do a new deployment you should run the deploy script from your Hyperion dev environment with e.g.
-
-.. code:: console
-
-    python ./utility_scripts/deploy/deploy_hyperion.py i03
+.. note::
 
+    When deploying on I24, the edm screens for serial crystallography will be deployed automatically along with the mx-bluesky release.
 
-If you want to test the script you can run:
 
+The script has a few additional optional arguments, which can be viewed with:
 
 .. code:: console
 
-    python ./utility_scripts/deploy/deploy_hyperion.py dev
-
+    python ./deploy/deploy_mx_bluesky.py -h
 
-and a released version will be put in ``/scratch/30day_tmp/hyperion_release_test``.
 
 For building and deploying a Docker image please see :doc:`../../hyperion/deploying-hyperion`.
 
 
 .. note::
-    
+
     On i03 the installation will succeed with error messages due to RedHat7 versions of a dependency being unavailable.
     This results in the installation being incomplete, thus requiring the following post-installation steps:
 
@@ -74,11 +47,11 @@ For building and deploying a Docker image please see :doc:`../../hyperion/deploy
 
         . ./.venv/bin/activate
         pip install confluent-kafka
-    
+
     Then, on the control machine, run
 
     .. code:: console
-        
+
         . ./.venv/bin/activate
         pip install -e .
         pip install -e ../dodal

docs/developer/hyperion/deploying-hyperion.rst

@@ -1,11 +1,11 @@
 Building a deployable Docker image
 ==================================
 
-Release builds of container images should be built by the github CI on release, ad-hoc builds can be performed via 
+Release builds of container images should be built by the github CI on release, ad-hoc builds can be performed via
 manual invocation of the Publish Docker Image workflow.
 
 Development builds of container images can be made by running the ``utility_scripts/build_docker_image.sh`` script.
-By default it will both build and push the image unless you specify ``--no-build`` or ``--no-push``. To push an image 
+By default it will both build and push the image unless you specify ``--no-build`` or ``--no-push``. To push an image
 you will first need to create a GH personal access token and then log in with podman as described below.
 
 Pushing the docker image
@@ -79,29 +79,29 @@ Then create and deploy the helm release
 
     ./utility_scripts/deploy/deploy_hyperion_to_k8s.sh --beamline=<beamline> --checkout-to-prod hyperion
 
-This will run the ``deploy_hyperion.py`` script to deploy the latest hyperion to ``/dls_sw``.
+This will run the ``deploy_mx_bluesky.py`` script to deploy the latest hyperion to ``/dls_sw``.
 You will be prompted to log into the beamline cluster, then it will create a helm release "hyperion".
-The source folders will be mounted as bind mounts to allow the pod to pick up changes in production. 
+The source folders will be mounted as bind mounts to allow the pod to pick up changes in production.
 For production these are expected to be in the normal place defined in ``values.yaml``.
 
 Development deployment
 ~~~~~~~~~~~~~~~~~~~~~~
 
-From a development ``hyperion`` workspace, either with a release image or using a development image built with the 
-script 
+From a development ``hyperion`` workspace, either with a release image or using a development image built with the
+script
 above, you install a dev deployment to the cluster you are currently logged into with ``kubectl``:
 
 ::
 
     ./utility_scripts/deploy/deploy_hyperion_to_k8s.sh --dev --beamline=<beamline> --repository=<your image repo> hyperion-test
 
 
-The dev deployment bind-mounts the current ``hyperion`` workspace and ``../dodal`` into the container so that you can 
-run against your own development code. **Clusters do not allow bind mounts from arbitrary directories so 
+The dev deployment bind-mounts the current ``hyperion`` workspace and ``../dodal`` into the container so that you can
+run against your own development code. **Clusters do not allow bind mounts from arbitrary directories so
 your workspace will have to be in a permitted directory such as your home directory.**
 
-By default the script will log into the ``argus`` cluster, if you want to deploy to an alternate cluster, 
-log in with ``kubectl set-context --current --namespace=<NAMESPACE>`` and then specify ``--no-login`` when running the 
+By default the script will log into the ``argus`` cluster, if you want to deploy to an alternate cluster,
+log in with ``kubectl set-context --current --namespace=<NAMESPACE>`` and then specify ``--no-login`` when running the
 script
 
 Please note, the deployment script is intended to be run from a checked-out matching version of the git repository.